GNOME Bugzilla – Bug 86540
Nautilus background steals colors from applications
Last modified: 2004-12-22 21:47:04 UTC
When a colorful Nautilus background is selected on a machine with a limited colormap default visual (e.g. Creator 3D ffbconfig -deflinear false) Then many X applications give "Warning: Xt Warning: Cannot allocate colormap entry for default background." errors and come up with color deficient displays and Icons. (White text on white backgrounds, missing or corrupt looking icons...) Suggested possibility is: "It appears that Nautilus isn't properly negotiating the best Visual for itself with Xsun. Sun framebuffers tend to offer the lowest possible visual as their root visual, while XFree86 on Intel-based hardware seem to offer their best as root. Solaris-built applications tend to know to ask for the visual they want and use that. Which is, pedantically, what the X standards tell you to do."
[Search for 'luis spamming' to catch every instance of this email.] In order to better track Sun's bugs for Sun and Ximian's internal use, I've added a temporary keyword to some bugs. I apologize for the spam, and for the use of an additional keyword, but this is the best way for Sun to track 'it's' bugs without interfering with the community's own triage and bug behavior. If you have any questions or objections, please drop me a note at louie@ximian.com or email bugmaster@gnome.org for more open discussion.
Can you attach the output of 'xdpyinfo'. GNOME apps should choose the best visual available. I think the code that does this is in gdk_rgb_choose_visual(). It always tries to get the highest depth visual available. So I'm a bit curious as to why this isn't working. On low-depth displays (e.g. 256 colors), I think gdkrgb will try to create a 6x6x6 color-cube, thus using 216 colors (though other apps are free to use them as well). You could change this to use a 5x5x5 color-cube, so more colors are free, but of course the display quality goes down.
Changing to NEEDINFO. I need to know the output of xdpyinfo to figure out what visuals were available and why GTK+ wasn't picking the best one.
Created attachment 9738 [details] xdpyinfo output on machine where nautilus background steals colors from icons.
The display has a max depth of 8, so I don't think it has a better visual we should be using. So GDK is creating a 6x6x6 color-cube and using up 216 of the 256 colors. How many/which X apps are failing? If they don't need specific colors that they can change dynamically, they should be using the closest color in the color-cube to the one they requested. Other options are to use a 5x5x5 color-cube, or maybe using one of the other visual types rather than PseudoColor, maybe DirectColor.
The problem is in gdk_rgb_score_visual(). It would give the same score to the 8-bit truecolor visual and the 8-bit pseudocolor one, but it scores the pseudocolor one higher because it also happens to be the system visual. I guess it is trying to economize on the number of visuals used, but that sounds like a doubtful decision to me. I think this bug will happen independently of how many colors there are on your background image, as pretty much everything in GNOME uses GdkRGB and the visual it chooses. I would rate truecolor visuals higher than pseudocolor ones of the same depth regardless of whether they are the system visual or not. For GNOME in your particular X server this would mean that it would run in the truecolor visual while "old-style" X apps run in the pseudocolor visual, thus getting the entire colormap for themselves, or in whatever visual they choose.
See the thread starting here: http://mail.gnome.org/archives/gtk-devel-list/2002-July/msg00103.html
Moving to GTK+.
(Why does a 64-bit machine come with an 8-bit video card, anyways?) :)
Adding wipro and sun.
Don't think we have the information here as to know how to proceed. (Please reopen if you add more information.)
Created attachment 10148 [details] Screenshot of CAD application with missing colors. When application takes focus, gnome looks much worse.
It doesn't help me to know that it improves things on one particular hardware combo; please see the gtk-devel-list thread.
Created attachment 10156 [details] xdpyinfo with creator 3d card deflinear false
Created attachment 10157 [details] xwininfo of nautilus background creator 3d with deflinears false.
Created attachment 10158 [details] Ignore previous xwininfo. This is desktop xwininfo on creator 3d with 24bit truecolor visual available
The right thing to do may just be to tame down the colorcube size as Keith suggested, but there are some problems with that. Another possibility would be to allow the user to specify their preferred visual ID in some fashion.
*** Bug 86543 has been marked as a duplicate of this bug. ***
Well this turned out to be a bug in libzvt and gnome-terminal. When i have any gnome-terminals open and i try to start sdtprocess or dtmail i get the following error Warning: Cannot allocate colormap entry for "seashell" Now if all the gnome-terminals open were to be closed and if sdtprocess or dtmail were to be run from the xterm console the sdtprocess and dtmail startup nicely with a lightish yellow background. On further investigation, the problem only occurs if gnome-terminal uses the Linux console and libzvt default color scheme is the same as the Linux console. Now in libzvt/zvtterm.c (zvt_term_set_color_scheme) when we are allocating colors for the new color scheme we dont free up the colors eariler allocated. If we free up the colors allocated earlier and if we refrain from using the Linux console color scheme, everything works fine. Attaching a patch for the freeing up the colors in zvt_term_set_color_scheme. I think we should be freeing the colors earlier allocated.
Created attachment 10962 [details] [review] Proposed patch for libzvt
Brian: Could you please apply the patch and see if you are able to reproduce the problem. You need to select a different color scheme say xterm in gnome-terminal and probably kill all instances of gnome- terminal to test it out.
Attaching a patch which fixes the problem, irrespective of the color scheme chosen in gnome-terminal. Brian: Could you please verify that the problem is with gnome- terminal/libzvt. Close all instances of gnome-terminal. Change the desktop background to a colorful one. Start other X applications from the Xterm console. If you are unable to reproduce the problem then the problem is only with libzvt, and this bug can be moved to libzvt.
Created attachment 10970 [details] [review] Proposed fix
Yes! This does seem to get rid of the worst of the colormap problems. Xscreensaver's password dialog still looks pretty bad and the window decorations are grainy looking, but I haven't seen the "unable to allocate color" messages with dt apps.
Could this bug can be moved to libzvt then? Brian: Could you file a separate bug under xscreensaver for the problems you are facing.
Reassigning the bug to the owner of libzvt...
okay to commit the patch to the HEAD? It's been in sun-patches for months, and fix's been verified enough, I think.
I'll go ahead and commit the patch. Thanks.