Re: pseudo transparency

Olivier Chapuis wrote:


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:

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


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.


Sasha Vasko

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