Re: pseudo transparency

Owen Taylor wrote:

Olivier Chapuis <olivier chapuis free fr> writes:

About the E method. Here there is a de facto standard which
uses the ESETROOT_PMAP_ID and the _XROOTPMAP_ID atoms. Maybe,
this can be documented in the wm-spec? If I well understand
this method, applications should use the _XROOTPMAP_ID and
setroot programs should destroy the pixmap if
before setting the background with its own pixmap (and
then set _XROOTPMAP_ID and also ESETROOT_PMAP_ID if its
own pixmap can be destroyed). That's it?

A program that wants to set the background should:

 - Create a persistant pixmap by calling to the server with:

    dpy = XOpenDisplay(display_name);
    XSetCloseDownDisplay (dpy, RetainPixmap);
    pmap = XCreatePixmap (dpy, DefaultRootWindow (dpy), width, height,
                           DefaultDepthOfScreen (DefaultScreenOfDisplay (dpy)));
    XCloseDisplay (dpy)

 - Grab the server

 - See if ESETROOT_PMAP_ID is set
 - If so, call XKillClient(xdisplay, *(Pixmap*)data_esetroot)

I'd like to see the result of that, if current root pixmap was created by window manager.

 - Change ESETROOT_PMAP_ID and _XROOTPMAP_ID to point to the
   new pixmap
 - Set the pixmap as the background for the root window

 - Ungrab the server
There is no point in checking to see if ESETROOT_PMAP_ID is
equal to _XROOTPMAP_ID ... if ESETROOT_PMAP_ID is set, it
will point to a pixmap that must be killed before changing

Iportant problem here is that you leave shared resource unprotected and unmanaged. Its as if you allowed client apps to set current colormap as they like.

Colormaps are actually another part of this particular issue, since it would be desirous for clients to obtain the colormap/visual with which such root pixmap was rendered.

Now one problem with the E method is that it may need
a lot of memory (this depends on the memory you have and

It takes _no_ extra memory. The pixmap is already referenced
by the server, all the E method does is keep around a XID pointing to the pixmap.

Not exactly correct. When you do XSetWindowBackgroundPixmap, what server does is it creates a protected copy of the pixmap. X protocol does not have clear requirement for this, but I'm yet to find a server that does not do that. So you normally use twice as much memory as needed with above approach.

Now workaround for this is to not set root background, but instead track Expose events on root window and do XCopyArea on it or XFillRectangle. This requires app to be present at all times, and breaks ParentRelative approach.

And still, there is this issue of transfering data from the server and onto the client in order to tint/shade it - note that pure root background is almost useless.

Also, it is quite possile that no app wil actually need transparency and you'll be wasting all that memory for nothing.

Note that selection method allows for all kinds of scenarios, and it is not all that difficult to implement, and could be even easier and more error-proof then current way of tracking sanity of _XROOTPMAP_ID.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]