Re: pseudo transparency

[Owen Taylor <otaylor redhat com>]

Sasha Vasko <sasha aftercode net> writes:

> The more flexible approach would be to use X Selections. WM-client
> protocol in this case would be something like :
> 
> 1) Window Manager, or whatever client is used to manage root
> backgrounds takes ownership of selection, say _NET_ROOT_BACKGROUND_S#
> ( one for each screen )
> 2) Client sets property on its own window with X,Y,Width,Height of the
> screen area it is interested in and optionaly destination Pixmap ID,
> and tint color in 32bit ARGB format (CARDINAL[6])
> 3) Client sends a SelectionRequest to the owner of
> _NET_ROOT_BACKGROUND_S# selection, with target PIXMAP and property atom
> naming the property it set up on its own window, and its window ID.
> 4) Selection owner cuts/tiles root background it knows about, and if
> tint color has been set - tints/shades it appropriately. Then it sets
> property on client's window to contain the ID of this resulting pixmap.
> 5) Upon receiving SelectionNotify client gets the Pixmap from its
> property (if operation was successfull).

(Much code to handle X selections doesn't handle sending data from
requester to owner, so this isn't necessarily easy to implement)

> This way way is more ICCCM compliant, resolves numerous problems with
> E approach and is more flexible when it comes to future extentions.

But it _needs_ to be extended. Simply making the pixmap available
means that the client can do whatever it wants with it.
 
> In particular :
> It allows root background to be stored outside of server's memory and
> possibly swapped out and/or compressed when its not being used (when
> there are no transparent apps running, for example).

Not having the root background set as the background pixmap of the
root window typically looks _very_ bad, so this doesn't strike me
as much of a gain.

> It allows for automation of cut/tint transformation of the pixmap,
> thus freeing clients from carrying its own imaging code, since
> cut/tint is all it is needed in 95% of the transparency apps.

Is it really better to require everyone setting the pixmap to have
this code? What if the client wants to do somethign else? (With
RENDER, tinting is actually just a few lines of code, so this
being "hard" at all will mostly go away soon.)

> It resolves age long issue when application were attempting to use
> root background after it has been destroyed.

Even minimally carefully written applications won't have a problem with 
this. (Trap error trap if you are accessing a pixmap you don't own)

> It allows WM to control when apps are alolowed to get root
> background. For example if app's window is being shaded  we may not
> want to let it update its background.

Assuming the window manager is the party setting the root background,
which is often not the case. A smart app would would never do anything
expensive with the background unless it was actually redrawing, which
would keep this from being a problem.

I think the ESETROOT method is actually pretty workable, if a little
hackish.  I'd be willing to write it up for freedesktop.org. (Havoc
says he doesn't want it in the WM spec. I tend to agree, if for no
other reason than it really isn't related to the window manager.)

Regards,
                                        Owen