User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Build Identifier: After a recent svn up of my xfce installation, and with the xfce compositor switched on, I notice that adesklets cannot properly grab the background image for its pseudo-transparency. All I see is background distortion or black. I am filing this here because updateing xfce was the only unit change i made to the system. Other applications that use pseudo-transparency for their background work fine (urxvt, conky, etc.). I should add that switching off the compositor (under tweaks) and restarting xfce causes the desklets to display properly, so this issue is seen only with the compositor on. I have made Sylvain the adesklets maintainer aware of the issue. I am filing this bug report for completeness. Was there any significant change recently in the way in which background images are manipulated in xfce, i.e at the WM level? I am using xorg 7.1, nvidia binary drivers 8774, adesklets 0.6.1, imlib2 1.2.1.009 and xfce svn of course. Reproducible: Always
I noticed that with gdesklets too, from times to times. The background pixmap is set by xfdesktop, the window manager has nothing to do with that. Reassigning.
Humm, not necessarily xfdesktop since it involves the compositor. Dunno then.
I did not check adesklets code, but from what I see, it seems that adesklets makes a copy of what's displayed on the root win at startup and use that to fake transparency. When a compositor is running, all windows are rendered off screen and painted by the compositor, so that it can draw shadows, use transparency, etc. (this is called "unredirection"). Up to Xorg 7.0 and its new concept of "overlay" windows, the compositor had to draw directly on the root window to render the final display, thus the problem you describe. I think the problem lies in adesklets way of doing things and should be fixed there in the first place. Another solution would be to change xfwm4 compositor to use Xorg 7.1 overlays, but Xorg 7.1 is far from being widely adopted by Linux distributions and the current design works just fine for what we need. If you could check with adesklets devels to see if my initial assumption of adesklets using the root window image to fake transparency is correct, then we would have the answer to the whole question :)
This is the technique he is using. Clearly it doesn't work anymore: /* Routine to grab the background in Imlib_Image. Returns NULL if it fails, Reference to output Imlib_Image otherwise. */ Imlib_Image xwindow_grab_background(Display * display, int screen, Window window) { int x, y; XEvent ev; Window src; XWindowAttributes attr; Imlib_Image background=NULL; if (!(display && window)) return NULL; if(XGetWindowAttributes(display,window,&attr) && /* Avoid reparenting coordinates translation problem */ XTranslateCoordinates(display,window,RootWindow(display,screen), 0, 0, &x, &y, &src)) { /* The trick is to create an Overrideredirect window overlapping our window with background type of Parent relative and then grab it. It seems overkill, but: - XGetImage() on root get all viewable children windows embedded. - XCopyArea() cause potential synchronisation problems depending on backing store settings of root window: playing around with GraphicsExpose events is not quicker nor simpler. This idea was taken from aterm source base. See src/pixmap.c in core distribution (http://aterm.sourceforge.net/). */ if((src=XCreateWindow(display, RootWindow(display,screen), x, y, attr.width, attr.height, 0, CopyFromParent, CopyFromParent, CopyFromParent, CWBackPixmap|CWBackingStore| CWOverrideRedirect|CWEventMask, &XDefaultWindowAttributes))) { xwindow_context_save(IMLIB_DRAWABLE|IMLIB_IMAGE); XGrabServer(display); XMapRaised(display,src); XSync(display,False); do XWindowEvent(display, src, ExposureMask, &ev); while(ev.type!=Expose); imlib_context_set_drawable(src); background=imlib_create_image_from_drawable(0,0,0, attr.width,attr.height,0); XUngrabServer(display); XDestroyWindow(display,src); /* Make sure image has an alpha channel */ imlib_context_set_image(background); imlib_image_set_has_alpha(1); /* Restore context */ xwindow_context_restore(); } } return background;
Yes, this is what I thought. I'm voting to close that bug then. BTW, why adesklets doesn't use _XROOTPMAP_ID, like other similar apps do? That would be simpler IMHO.
Very true, but i think it's not the case that the _XROOTPMAP_ID and ESETROOT_PMAP_ID properties are set in some environments. Do you think that getting the background pixmap from _XROOTPMAP_ID would be more effective under xfce, even with the compositor on?
(In reply to comment #6) > Do you think that getting the background pixmap from _XROOTPMAP_ID would > be more effective under xfce, even with the compositor on? Sure! It's what gdesklets seems to do and it seems to work just fine.
OK I relayed all this information to Sylvain Fourmanoit, the adesklets author. He appreciates the input and will try implementing the _XROOTPMAP_ID method instead of using parent-relative. I'm out of the loop now and am marking this bug resolved invalid. Thanks much for your help.