GNOME Bugzilla – Bug 747524
System tray icons fail to redraw correctly on Xfce (without display compositing)
Last modified: 2015-04-20 09:34:45 UTC
Created attachment 301153 [details] Test tray icon application (This is a follow up from bug 737986 and bug 738670, so that it can be properly tracked and not add noise to those bugs.) The issue started happening after the following commit: commit dae447728db32a5a7162d9216f2e2343837cbae4 Author: Alexander Larsson <alexl@redhat.com> Date: Wed Oct 29 12:35:07 2014 +0100 X11: Pick better system and rgba visuals for GL * The issue is affecting gtk3 status icons in the Xfce panel systray area and only occurs when the screen isn't composited. Icon updates are drawn on top of the previous icon and, when new status icons are added to the tray, their background is black instead of transparent. * The Xfce panel (that contains the systray manager) uses the system default visual with ID 0x21 and sets the _NET_SYSTEM_TRAY_VISUAL property to the same value. * I start my test gtk3 application which creates a GtkStatusIcon. The application's root window uses the visual with ID 0x20e (which selected by default in gtk 3.16.0). Before the status icon is realized, its visual is set to 0x21. Immediately after this, the widget's window is created and that also uses the visual 0x21. Bellow is the 'glxinfo -v' output for both visuals: Visual ID: 21 depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N auxBuffers=0 depthSize=24 stencilSize=8 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque. Visual ID: 20e depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=24 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=0 float=N sRGB=N auxBuffers=0 depthSize=0 stencilSize=0 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque. Another visual I tried (instead of 0x20e) but still didn't work: Visual ID: 1e0 depth=24 class=TrueColor, type=window,pixmap,pbuffer bufferSize=32 level=0 renderType=rgba doubleBuffer=1 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8 float=N sRGB=N auxBuffers=0 depthSize=24 stencilSize=0 accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=None Opaque.
Created attachment 301346 [details] [review] [PATCH] x11: Relax requirements for setting ParentRelative After much poking around, the issue turned out to be that ParentRelative wasn't being set at all, due to an overly restrictive condition that required the window to have the same visual as its parent. The attached patch avoids setting ParentRelative only in the very specific case that the parent window has a different depth. The exact same condition (parent && window->depth != parent->depth) is in xserver and, from what I can see, the only way the XSetWindowBackgroundPixmap() call will result in a BadMatch error. In my testing this fixed the gtk3 status icons in Xfce's systray.
Nice detective work! Thanks for the patch
Review on irc: ebassi> mclasen: That's a bit of X guts that I'm not entirely familiar with alex> It sounds good, but i have not verified the claim that X only badmatches with depth being different alex> lemme look if (pWin->parent && pWin->drawable.depth != pWin->parent->drawable.depth) { alex> mclasen: yeah, so that patch looks good to me
Stumbled through this patch while reviewing the recent changelog... is it intentional that the behavior was changed for the parent = NULL case?
(In reply to Paolo Borelli from comment #4) > Stumbled through this patch while reviewing the recent changelog... is it > intentional that the behavior was changed for the parent = NULL case? Bahavior hasn't changed; setting the background pixmap of a root window to either None or ParentRelative is special-cased in xserver and has the same effect. In both cases SetRootWindowBackground() gets called (with the same parameters), which also contains this relevant comment: /* following the protocol: "Changing the background of a root window to * None or ParentRelative restores the default background pixmap" */ As I mentioned in the comment with the patch attached, the same condition (parent && window->depth != parent->depth) is used in the xserver code. We want to avoid triggering a BadMatch error, so using an identical check is a good way to do this.