GNOME Bugzilla – Bug 150465
Metacity uses wrong colormap to convert RGB values to X pixel values.
Last modified: 2009-01-19 20:20:55 UTC
The following trivial patch is required to ensure that metacity uses the correct colormap to convert RGB values to X pixel ones. This is an issue when the new X.org server is being used along with a compositing manager. In this case if metacity inherits the ARGB visual from an ARGB application then a colormap associated with a default visual is used instead of that associated with the ARGB visual. This has the upshot of making it impossible for any parts of Gtk to determine that the alpha bits need to be set in the X pixel values. Note that to ensure correct behaviour on both sides a corresponding GDK patch will also be needed so that pixel values are set correctly if the visual is an ARGB one. diff -u -r1.70 theme.c --- theme.c 10 Jan 2004 17:16:06 -0000 1.70 +++ theme.c 18 Aug 2004 16:38:20 -0000 @@ -2663,7 +2663,7 @@ meta_color_spec_render (color_spec, widget, &color); values.foreground = color; - gdk_rgb_find_color (widget->style->colormap, &values.foreground); + gdk_rgb_find_color (gdk_drawable_get_colormap(drawable), &values.foreground); values.line_width = line_width; gc = gdk_gc_new_with_values (drawable, &values,
See bug #150466 for GDK-side of this bug.
Looks good to me. A related patch that may not be in bugzilla: http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00419.html http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00511.html
On a related note (using per-drawable styles) it is probably more 'correct' to set the background colour for ARGB visuals to be black with alpha = 0. This is to make sure that themes which have 'holes' in render correctly.
Created attachment 30722 [details] Screenshot of 'metacity using theme with alpha map Screenshot of metacity with modified PNG theme. PNG was modified in GIMP to have a hole drilled out. With default background set to black, alpha = 0 background shows through as expected.
Nice, that makes sense. Do mouse clicks automatically pass through alpha regions, or is extra work needed to get the input right?
More work will be needed there, probably using Shape in metacity to cut out areas with alpha = 0. This will also make transparent themes work in a slightly more expected manner using classic X. xcompmgr will need a little work too in this regard as it currently appears to ignore the Shape of windows when compositing. This is most clear in the Bluecurve theme where the rounded corners aren't rounded. It would theoretically be possible for xcompmgr to use the new Xevie extension (or whatever its called) to pass clicks on alpha=0 regions to lower windows but thats suboptimal for at least two reasons; it requires a round trip * number of transparent windows per click and also will stop apps doing cunning things with ARGB windows overlayed onto the screen (providing overlays etc.). On a side-note Gtk also will need a little haxie to deal with drawing non-alpha pixbufs in ARGB visuals to force it to use the Render extension (I think its reasonable to expect a server with ARGB visuals will have Render) since Render knows best about how to composite onto the ARGB visual (better than GtkRGB does anyhow). But then thats a whole other bug :).
Created attachment 30745 [details] Sexy shading in metacity OK, I've worked out all the GDK and metacity patches required to do nice things (see screenshot). Here you can see a modified Simple theme where the background is a 'tint' rather than a 'rectangle' so they are translucent. Titlebar text and buttons are still 100% opacity however (as intended). The actual patches are fairly clean and I'll open a new bug once I've got them ready but you can see how nice this looks. Themes will not be able to take advantage of ARGB-enabled Xservers with no extra effort :) In total there is about 20 lines difference and should provide identical behaviour for legacy X servers.
replace 'not be able to' with 'now be able to' above :).
Created attachment 30747 [details] [review] Patch against CVS to add ARGB visual support to metacity Patch to enable the eye-candy in previous screenshot. This patch adds the following features: 1) If an ARGB visual is available, use it by default for all windows. 2) If an ARGB visual is used for a window, set the default background colour to 100% transparent. Original behaviour otherwise. 3) Use correct Colormap for converting RGB -> XPixel values as original patch. Possible issues: The ARGB visual detection is done by Xrender but isn't wrapped by a check that the extension is present. Adding this is fairly easy and could be done if required or it could be left as an exercise for the commiter :).
Opened bug #150537 to have complete GDK-side fix. Both patches must be applied for eye-candy to work.
Created attachment 30771 [details] [review] Cleaned up patch This patch adds the #ifdef HAVE_RENDER and fixes coding style issues, I don't think it has functional changes worthy of note. I haven't tested it, so am not committing it yet. But if people say it works I'll check it in.
Am at O'Reilly's FooCamp at the moment. Will check patch when I get back on Tuesday. It applies, compiles and appears to run correctly though (limited testing can be done over SSH from another country :)) and a screenshot via xwd appears to show it working.
Created attachment 30921 [details] [review] Modified patch against current CVS Modified the patch so it applies against current CVS. Checked in front of machine now and confirmed that it works perfectly. Still some work needing to be done on rounded window borders but suggest this patch be applied first to give something to build on.
We should just commit this then I think.
I had to back this out partially; it broke e.g. the Bluecurve theme which did not explicitly paint the whole background, but left it the default. Then with this patch the window borders were messed up. So I think what we need to do is in new bugs #151261 and #151262 Of course, #102547 is a little bit pesky.
I'm guessing that the older patch is obsoleted by the newer one, and I think Havoc's later comments count as review, so I'm going to mark the last patch as commented-on. Kick me if this isn't right (I'm trying to make it easier to find important unreviewed patches by kicking the obviously reviewed ones off the http://bugzilla.gnome.org/reports/patch-report.cgi?product=metacity list). :)
Reassigning to the compositor component as per bug 151918 comment 8. :-)
This is assigned to Søren's compositor, which no longer exists. Iain, is this something which applies to your compositor, or should we just OBSOLETE this bug?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!