65881 - mozilla appears to be using two colormaps

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Alan Stange]

I wanted Mozilla to use an installed colormap, as I have an 8 bit frame buffer.

So, I modified nsAppshell.cpp to actually handle the colormap prefs such that
an installed colormap would be used.  This worked fine.

Except that the colors used by the theme appear to be allocated from the primary
color map still.  So, in the modern theme, the blues and greys from the button
bar are not coming from the installed colormap.

Comment 1

[Keyser Sose]

Reporter you dont happen to have that patch handy you made do you?

Comment 2

[Alan Stange]

I don't have a diff handy, but the change is trivial.  In
widget/src/gtk/nsAppShell.cpp, there is a function HandleColormapPrefs().  
Add

gdk_rgb_set_install( TRUE );
return;

at the top of the function.

The same effect can be had by changing modules/libpref/src/unix/unix.js
so that 
pref("browser.installcmap", true);

instead of the default false value.

I tried to set the ncols as well, but that doesn't appear to work at all.  I
guess that should be reported as another bug...

I did add these preferences to my ~/.mozilla/default/prefs.js and they were
ignored.  I don't see why they should be ignored.  Seems to me that anything I
add into my prefs.js should override something built into mozilla.

Comment 3

[Peter Trudelle]

hmm, not sure about ownership here. Pav, should you field this?

Comment 4

[Asa Dotzler [:asa]]

setting bug status to New.

Comment 5

[Stuart Parmenter]

syd, you did some of the colormap stuff.. wanta look at this?

Comment 6

[Stuart Parmenter]

handing over to syd to investigate

Comment 7

[Dan Dickerman]

I also ran into this when making modifications for a private colormap as you
did, and which now can be seen without source modification on mozilla 1.0 using
the "-install" option, due to the fix of bug #22337.  When a private colormap is
installed by gtk (either forced with -install or by its own selection due to low
available colors), the rgb library uses one map, and mozilla draw in another.  I
have been able to get reasonable results by adding a line in
widget/src/gtksuperwin/gdksuperwin.c to associate the colormap chosen by gtk_rgb
with the window at creation:

  attributes.colormap = gdk_rgb_get_cmap();
  attributes.visual = gdk_rgb_get_visual();
  attributes.event_mask = GDK_VISIBILITY_NOTIFY_MASK;

  attributes_mask = GDK_WA_COLORMAP | GDK_WA_VISUAL | GDK_WA_X | GDK_WA_Y;

 [ The line with gdk_rgb_get_cmap() is new, as is the GDK_WA_COLORAP flag ]

What's also odd is that while the colormap is now chosen correctly, and the
browser space is properly dithered for reasonable images in a 6x6x6 color cube,
the theme-based menu area is not dithered, which looks... a bit stripey when
using the modern theme, or any theme with gradiated colors.  I recall that this
was not the case in earlier versions (though I've deleted all the old
milestones, so I can't dig for the exact change).  Similarly low-color dithering
for the theme'd areas is shown in the examples for Bug #22058 (over 2 years
ago), which comments on the difficulty of using such themes when few colors are
available.

Comment 8

[Salim Virji]

installing and testing suggested fix.

Comment 9

[Jay Yan]

see also bug 160405

Comment 10

[Martin Lawyer]

Attachment: Patch with change suggested by Dan Dickerman

This change has been checked into the OEM branch (a=jdunn, r=syd, sr=blizzard).
 Trunk still needs updating.

Comment 11

[Jay Yan]

since the patch for bug 160405 has already got sr= form blizzard and has been
checked into OEM_BRANCH, can we checkin this patch into trunk now?

So we do not have to duplicate the same process for the next release:)

is it OK to check it into trunk now?

Comment 12

[Martin Lawyer]

The patch as it went into the OEM branch (attached) was ifdef'd for specific OEM
platforms, so Linux is not included.  It should probably get reviewed/approved
for Linux, then possibly checked in without the ifdefs.   

Comment 13

[Martin Lawyer]

Attachment: Screen shots of icons with colormap problems

The attached image shows the mozilla icons with messed up color maps (bottom
row) when mozilla is launched with the "-install" option (which was added for
bug 22337).   Top row is without "-install". 

This problem was discovered while testing the fix for bug 160405 (OEM branch
duplication of bug 65881).  Should it be part of this bug, or opened
separately?

Comment 14

[Dan Dickerman]

I believe that is the problem described in bug #114929 -- whenever the browser
windows and the desktop use different colormaps, the colormap chosen for the
icon needs to be explicitly chosen as that of the desktop.  That's sort of the
reverse of this bug: where the colormap chosen for the window must be explicitly
different from that of the desktop in this case.  Check that bug for the 4-line fix.

Comment 15

[Philip walden]

I am using the 1.3a build for HP-UX 10.20 on a HP C3000 dual colormap challenged
system.

I can not only confirm the icons are color mangled, but also the (tool, menu,
status, navigation, etc) bars also have color issues.

Comment 16

[Philip walden]

BTW Dan Dickerman privately provided me a patched version of Mozilla 1.0 that
did not exhibit the * bar color problem on a HP-UX 11.0 C3000 with similar
hardware configuration.I believ it was built using the changes suggested in
comment #7

Comment 17

[tor]

Attachment: get private colormap option working

There were a couple problems:

  * we were calling gdk_rgb_set_install() way too late, as the gtkrc parsing
    triggered by nsAppRunner causes gdk_rgb_init() to be called.

  * native widgets were drawing with the wrong visual/colormap, so they
    didn't match the colormap being used by the rest of the content.

Comment 18

[tor]

Checked in.

Comment 19

[Philip K. Warren]

Comment on attachment 131566 [details] [diff] [review]
get private colormap option working

This patch is much better than the previous ones that were committed, and it
really makes a difference on machines with older graphics cards. It would be a
good improvement for both the 1.4 branch and for the 1.5 release.

Comment 20

[Asa Dotzler [:asa]]

Comment on attachment 131566 [details] [diff] [review]
get private colormap option working

1.5 shipped. removing obsolete request.

Comment 21

[Mike Kaply [:mkaply]]

Comment on attachment 131566 [details] [diff] [review]
get private colormap option working

a=mkaply for 1.4 branch (1.4.2)

Comment 22

[tor]

Checked in on MOZILLA_1_4_BRANCH.

Comment 23

[simon derr]

Attachment: screen shot showing wrong colors in menubars and configuration window when a private colormap is used

Comment 24

[simon derr]

Comment on attachment 141222 [details]
screen shot showing wrong colors in menubars and configuration window when a private colormap is used

problem still appears on firefox 0.8

I'm running firefox on a Linux PC and my display is a NCD Explora pro X
terminal

Comment 25

[tor]

Are you using gtk2?  If so, that's bug 233212.

Comment 26

[simon derr]

(In reply to comment #25)
> Are you using gtk2?  If so, that's bug 233212.
> 

$ ldd firefox-bin | grep gtk
        libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x401d7000)

No.

Comment 27

[tor]

Fire* forked nsAppRunner.cpp and doesn't have the necessary changes to
make private colormaps work.

Comment 28

[tor]

Fire* changes are in bug 235034.