Re: pseudo transparency

[Owen Taylor <otaylor redhat com>]

Sasha Vasko <sasha aftercode net> writes:

> 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
> >>	ESETROOT_PMAP_ID == _XROOTPMAP_ID
> >>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.

See above - the pixmap is created as the only resource of a persistant
client, so the setter can exit. If you don't want to do this, then
you kill the previous ESETROOT_PMAP_ID, unset ESETROOT_PMAP_ID and
set only XROOTPMAP_ID.
 
> >  - 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
> > ESETROOT_PMAP_ID.
> 
> 
> 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.

This is indeed somewhat of an issue. I don't think it's really worth
the complexity of a whole new protocol, since even negotiating this
doesn't provide a nice user interface to the user. Making sure
that the background is set by only one app is the responsibility
of the person configuring the desktop.
 
>  > >>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.

Making a copy wouldn't even be conformant to the X protocol. I can
set the pixmap, change the pixmap, and subsequent exposes will
reflect the change. I invite you to read the XFree86 sources and
see if you can find the copy.
 
> 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.

(Also, looks really bad.)
 
> 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.

 a) You can do it all on the server if you have RENDER 
 b) Transferring data server to client and back is actually pretty
    darn fast, especially if you used ShmImages/ShmPixmaps. (Did a lot
    of timing of this over the last few weeks.)

And also, the background setter will need to keep a copy of the data
if it is going to tint it, so now we _do_ have two copies of the 
data.

Regards,
                                        Owen