Re: pseudo transparency

[Sasha Vasko <sasha aftercode net>]

Olivier Chapuis wrote:

> Hi,
>
> There is two methods that an application can use to achieve
> "pseudo transparency".
> One method, the E method, is to have a pixmap in memory and
> to indicate the id of this pixmap with a root atom. The second
> method is to use parental relativity.
> Each method has some advantages I do not think that the wm-spec
> should choose one of them. I think that it will be good that
> the wm-spec support both.
>
> One problem with parental relativity is that a priori the
> application has to set the background of the frame window(s)
> set by the window manager. It seems to me that this leads to
> a bad hack. So I suggest to add a new window state:
>
>   _NET_WM_STATE_PARENTRELATIVE_BACKGROUND indicates that the window
>   use the ParentRelative pixmap for its background. The window manager
>   should set the frame window(s) background accordingly.


The problem is that some window managers may not be able to set frame's 
background to ParentRelative. For example window manager may need to use 
 frame's window to actually draw some decorations on it, or draw 
interwidget spacing with some specific color. Therefore in addition to 
the property on client window - there needs to be a property set by 
window manager that informs everybody that it could actually support it, 
so that application can choose alternative method.


> maybe the name is bad and also maybe it is better to have a
> separated atom for this property. The advantage of using a state
> is that an application can ask to set/unset this property.
>
> 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?
>
> Now one problem with the E method is that it may need
> a lot of memory (this depends on the memory you have and
> the size of your screen(s)). So, some environment/users

<snip>

As you said this method requires that background image is always kept in 
 X Server's memory as a Pixmap, and when full screen background is used 
it leads to several megs of wasted memory. It also does not cover the 
case when root background is kept in Window Manager's own memory, which 
makes alot of sense since WM would need it to be able to draw 
(semi)transparent decorations.

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).

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

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).
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.
It resolves age long issue when application were attempting to use root 
background after it has been destroyed.
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.

> Olivier


Sasha Vasko