! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfce compositor + adesklets pseudo-transparency


Description Philip Kovacs 2006-09-17 23:10:28 CEST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060909 Firefox/
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 and xfce svn of course.

Reproducible: Always
Comment 1 Olivier Fourdan editbugs 2006-09-18 06:50:20 CEST
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.
Comment 2 Olivier Fourdan editbugs 2006-09-18 06:51:58 CEST
Humm, not necessarily xfdesktop since it involves the compositor. Dunno then.
Comment 3 Olivier Fourdan editbugs 2006-09-18 11:39:15 CEST
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 :)
Comment 4 Philip Kovacs 2006-09-18 20:27:34 CEST
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.
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 */
			   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/).
			  x, y, attr.width, attr.height,
			  CopyFromParent, CopyFromParent, CopyFromParent,
			  &XDefaultWindowAttributes))) {
	XWindowEvent(display, src, ExposureMask, &ev);
      /* Make sure image has an alpha channel */
      /* Restore context */
  return background;

Comment 5 Olivier Fourdan editbugs 2006-09-18 20:42:21 CEST
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.
Comment 6 Philip Kovacs 2006-09-18 21:14:40 CEST
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?
Comment 7 Olivier Fourdan editbugs 2006-09-19 08:33:24 CEST
(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.

Comment 8 Philip Kovacs 2006-09-19 20:19:16 CEST
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.

Bug #2332

Reported by:
Philip Kovacs
Reported on: 2006-09-17
Last modified on: 2009-07-15


Olivier Fourdan
CC List:
0 users



Additional information