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.

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

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.

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

setting bug status to New.

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

handing over to syd to investigate

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.

installing and testing suggested fix.

see also bug 160405

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

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?

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.

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?

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.

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.

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

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.

Checked in.

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 on attachment 131566 [details] [diff] [review] get private colormap option working 1.5 shipped. removing obsolete request.

Comment on attachment 131566 [details] [diff] [review] get private colormap option working a=mkaply for 1.4 branch (1.4.2)

Checked in on MOZILLA_1_4_BRANCH.

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

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

(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.

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

Fire* changes are in bug 235034.