98802 - Ungraceful display on a 8-bit PseudoColor Visual

Status: VERIFIED DUPLICATE of bug 22337

(SeaMonkey :: UI Design, defect)

Description

[Shanmugavelu Shanmuganathan (gone)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.3+) Gecko/20010829
Netscape6/6.1b1
BuildID:    2001090617

If the X-server runs with "PseudoColor" as the default visual,
the images, background colors, and fonts are badly dithered. In order
to avoid this the user may be warned about the fact that his X-Server
is running with the "PseudoColor" as the default Visual and he may
use the TrueColor visual as the default visual. (Could have been nice
if mozilla supported the "-visual" option to specify the visual class
in the command line). 
   I have seen this problem on a Redhat Linux 6.2 too. 
The information that we tell the user,  using a popup window, could be 
crucial, so that he can switch the visual class.  

Reproducible: Always
Steps to Reproduce:
1.Start mozilla on a UNIX machine whose X-Server with 8-bit PsedoColor
by default.
2. 
3.

Expected Results:  The images, background colors and fonts will be dithered. 

This is a  problem in all the UNIX platforms. 
I have a patch  for this, which I will attach soon. Since the patch
will display a message, this needs internationalisation.

Comment 1

[Shanmugavelu Shanmuganathan (gone)]

Attachment: Fix to pop-up a windoe to warn the user if the default visual is "pseudoColor"

Comment 2

[Keyser Sose]

Marking NEW so this patch can get checked in.

Comment 3

[Christopher Blizzard (:blizzard)]

This is a bad work around.  Why is gtk picking that crappy visual when other
visuals exist?

Comment 4

[Jim Dunn]

If the default visual is pseudo-color I believe if you open
a window without specifying a visual you get the default one.
(at least that is how X worked, and I assume that gtk is no better)

However, we are now talking 2 problems
-if you have an 8bit adapter (rare but not that rare) then our
 color scheme is bad
-it sounds like we just use the default visual instead of picking
 one that is best for us (in terms of color, performance...)

The last time I messed with visuals was at least 8 yrs ago and
while I remember it was confusing, writing a simple visual picker
based on what is available wasn't that bad.  However, fixing our
color scheme is a bit more work.  BUT I know Syd played around
with this in 4.x and maybe he can suggest something. 

Comment 5

[Shanmugavelu Shanmuganathan (gone)]

Jim, 
	As you know, in Mozilla there is no way to select the "visual" option 
from the  command line, while  Netscape 4.7 has it.  And it looks a 16-plane 
depth  visual class is the minimum depth under  which Netscape 6.1 will 
display without dithering it's "skin". Is it (dithered image) unavoidable 
if I have a 8 bit adapter? 

Comment 6

[Christopher Blizzard (:blizzard)]

Gtk doesn't just "pick the default visual" it actually has a rating system that
goes through the list of visuals available and picks the one that works the
best.  It sounds like in this case that there's something going wrong and it's
picking an 8 bit visual when there's something better available, right?

Comment 7

[Shanmugavelu Shanmuganathan (gone)]

Here is the complete display information.
"xdpyinfo" shows many visuals with 8-plane depth are available.
While xwinfo shown the PseusoColor visual (the default in this case)
with 8-plane depth is picked by mozilla.  But I get a neat display 
on a machine whose visuals are 16-plane  depth.  So the observation here 
is that Mozilla requires a minimum of 16-plane depth visual class 
to display without dithering the colors. Is that true?
  

mainz.mcom.com> xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    DECWINDOWS Digital Equipment Corporation Digital UNIX V4.0
vendor release number:    1
maximum request size:  4194300 bytes
motion buffer size:  100
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    6
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 12, bits_per_pixel 32, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x3800044, revert to Parent
number of extensions:    20
    Adobe-DPS-Extension
    BIG-REQUESTS
    DEC-XTRAP
    DOUBLE-BUFFER
    DPMS
    DPSExtension
    Keyboard-Management-Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    Multi-Buffering
    SHAPE
    SYNC
    Shared-Memory Transport
    XC-MISC
    XIE
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1280x1024 pixels (342x274 millimeters)
  resolution:    95x95 dots per inch
  depths (1):    8
  root window id:    0x2d
  depth of root window:    8 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x21
  default number of colormap cells:    256
  preallocated pixels:    black 1, white 0
  options:    backing-store YES, save-unders YES
  largest cursor:    64x64
  current input event mask:    0x30003c
    ButtonPressMask          ButtonReleaseMask        EnterWindowMask          
    LeaveWindowMask          SubstructureRedirectMask FocusChangeMask          
  number of visuals:    10
  default visual id:  0x22
  visual:
    visual id:    0x22
    class:    PseudoColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x23
    class:    PseudoColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x24
    class:    DirectColor
    depth:    8 planes
    available colormap entries:    8 per subfield
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x25
    class:    GrayScale
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x26
    class:    StaticGray
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x27
    class:    StaticColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x28
    class:    TrueColor
    depth:    8 planes
    available colormap entries:    8 per subfield
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x29
    class:    TrueColor
    depth:    8 planes
    available colormap entries:    8 per subfield
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x2a
    class:    TrueColor
    depth:    8 planes
    available colormap entries:    8 per subfield
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x2b
    class:    TrueColor
    depth:    8 planes
    available colormap entries:    8 per subfield
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits

=======================================================
mainz.mcom.com> xwininfo 

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x440008c "Netscape 6 {Build ID: 2001090617}"

  Absolute upper-left X:  58
  Absolute upper-left Y:  58
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 640
  Height: 480
  Depth: 8
  Visual Class: PseudoColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +58+58  -582+58  -582-486  +58-486
  -geometry 640x480+52+29

Comment 8

[Christopher Blizzard (:blizzard)]

Well, _technicaly_ even with 16 bit depth you're dithering but the eye can't see
it because there are roughly 65k colors so it might as well be real color.  But
with 8 bit you are definitely dithering.

So, the question still stands, why are we picking a bad visual?

Comment 9

[Jim Dunn]

Unless I am interpretting the posts to this bug wrong,
we are NOT picking a bad visual.  Only 8bit visuals
are available, so we pick one of them, we set our colormap/table
and start using it.  Once we set the colormap (our own)
when ever our window is in focus, the other windows go
wacky because there are only 256 colors available and their
index #1 is not the same as our index #1 hench the technocolor effect.

My guess is that the adapter is only 8bit, so the only visuals
supported are 8bit.

I think when we are stuck with an 8bit visual we need to do a better
job of using the existing colormap instead of creating our own
(note I am assuming we are creating our own)

Comment 10

[Christopher Blizzard (:blizzard)]

Oh!  Duh.  I'm a moron.

So are we actually switching colormaps?

Comment 11

[Cindy Roberts]

There aren't any comments on this bug since the 13th of
Sept.  Can QA regess against the Netscape commercial builds and determine if
this is still a valid bug?  If so, and we can get fixes/reviews in the next day
or two, please mark as nsbranch+ which will get this on the PDT radar.  Also,
can someone comment in the bug how serious you think this is?  PDT is only
accepting "stop ship" bugs such as data loss and loss of major functionality.

Comment 12

[Shanmugavelu Shanmuganathan (gone)]

Tnis is not a stop ship bug, as this is only a display problem
only on machines with 8-bit adapter. However it would be nice if this
is fixed in the future.

Comment 13

[Cindy Roberts]

PDT is only accepting "stop ship" bugs at this point such as data loss, loss of
major functionality, regressions and bugs to the eMojo "stop ship" features. 
Based on the last comment, can someone mark as nsbranch-?

Comment 14

[Shanmugavelu Shanmuganathan (gone)]

Marking this as nsbranch-

Comment 15

[Malcolm Box]

As an additional data point, Moz Modern chrome looks terrible on Windows in 256
color mode as well, unlike 4.7x in which the chrome looks fine.

This bug is related to bug 22337 as well, which suggests the best way forward
would be to:

1) Create a low-colour skin for use on 8-bit displays (needed for Win32, since
you can't install a colourmap)
2) Auto-detect low colour visuals and install a colourmap, or use the existing
prefs option

Comment 16

[Jaime Rodriguez, Jr.]

is this patch ready to go? if yes, we should try and get it in for 099.

Comment 17

[Shanmugavelu Shanmuganathan (gone)]

This patch is only to warn the user about the display problem and 
nothing more than that. The best solution will be to solve it in
one or other way.

Comment 18

[Rob Jaworski]

shanmu, were you planning on getting that patch in?

Comment 19

[Shanmugavelu Shanmuganathan (gone)]

Looks like this problem is solved already. 
http://bugzilla.mozilla.org/show_bug.cgi?id=112635
I checked this in a machine that has 8-bit depth and mozilla
looked good in it.

Comment 20

[Martin Lawyer]

Using Mozilla 1.0 (RC3) on an HPUX machine with an 8-bit video card (Mozilla 
always runs in "PseudoColor" display):

Test one:
Bring up Mozilla first, default visual is "PseudoColor", display looks normal.
Exit.

Test two:
Bring up another app first (Communicator 4.79), PseudoColor display looks 
normal. 
Bring up Mozilla (479 still running), and the display is very bad.  Obviously 
not enough colors to go around. 
Exit both.

Test three:
Bring up 479 with "-visual TrueColor".  Display looks normal.
Bring up Mozilla (479 still running in TrueColor), Display looks normal.
Exit both.

At no point did a window pop up to warn the default visual was "PseudoColor"

Conclusion:  It doesn't look like this bug is fixed for HPUX.

Comment 21

[Shanmugavelu Shanmuganathan (gone)]

Mozilla's display looked bad on a 8 bit display.  The first 
suggestion to warn the user about the display settings was 
not considered as a solution. The  solution would be to make
Mozilla look better even on a 8-bit display. This was solved 
by bug id=22337. This is the reason why mozilla looks normal
now. The  patch to pop-up a warning window was never submitted. 
if there are no outstanding issues, I will mark this bug as fixed, 
dup of bug 22337.

Comment 22

[Martin Lawyer]

I've been able to determine that the fix for bug 22337 is not working properly
on HPUX.  We may need to open an HPUX specific bug on the problem. 

Comment 23

[Martin Lawyer]

http://bugzilla.mozilla.org/show_bug.cgi?id=22337#c45

Summary:  bug 22337 adds recognition of the "-install" option, and is done, but 
bug 65881 actually adds the code for using it, and is not done.  

Comment 24

[Asa Dotzler [:asa]]

*** Bug 182590 has been marked as a duplicate of this bug. ***

Comment 25

[Andrew Schultz]

doing what shanmu said to do in comment 21

resolving as dupe of "Possible to install colormap on 8 bit displays"

*** This bug has been marked as a duplicate of 22337 ***