GNOME Bugzilla – Bug 86543
metacity window decorations appear to use the default visual
Last modified: 2004-12-22 21:47:04 UTC
metacity window decorations appear to use the default visual rather than negotiate the best visual with XSun. When ffbconfig -deflinear false is set on a creator 3D card, the wondow decorations look grainy.
should probably just use the gdk_rgb_get_visual() visual instead of the default. easy enough to change. (One wonders why the X server bothers to default to 8 bit if nothing will use it, but ;-)
Probably something sun and wipro should be aware of even if it isn't really high priority for the community.
This problem isn't really specific to metacity or nautilus, it is anything that uses gdkrgb.c. Nautilus bug 86540 has the most information about this so I'll mark this as a duplicate of that. *** This bug has been marked as a duplicate of 86540 ***
No, this isn't a duplicate of Nautilus bug 86540 :( Metacity doesn't use gdkrdb: See colors.c: ... /* Now this is a low-bloat GdkRGB replacement! */ if (INTENSITY (r, g, b) > 0.5) pixel = WhitePixel (screen->display->xdisplay, screen->number); else pixel = BlackPixel (screen->display->xdisplay, screen->number); #undef INTENSITY ...
colors.c is an unused file, you should ignore it. The relevant code is in frame.c, look for the XCreateWindow(). Note the comment about DRI, some visuals don't work for frame windows. I'm not sure how to choose a visual that's guaranteed to work. It's easy to make a patch to use the GdkRGB visual obviously. Add a function to ui.[hc] meta_ui_get_frame_visual() perhaps. (I still think it's kind of crap to have a default visual then have all apps independently ignore it and decide to default to something else, what does "default visual" mean in that case, but.)
Thanks for the info. I'll try to find how to determine if a visual supports frame windows. GtkRGB isn't quite right yet, but if I can get it to pick a best visual for other gnome apps which supports frame windows, it might be better than the default visual for metacity. Part of the reason I have to support setting the default visual to 8 bit nonlinear is that some legacy applications always use the default visual and always expect it to be 8 bit nonlinear.
Since gdk_rgb_get_visual() returns an 8 bit pseudocolor visual even when 24 bit visuals are available, this change didn't help.
It appears that the bad behavior was actually caused by a color leak in gnome-terminal. (See http://bugzilla.gnome.org/show_bug.cgi?id=86540) Havoc, thanks for the suggestions. I agree that without the side effects caused by application colormap leaks, the existing behavior is reasonable.