Re: pseudo transparency
- From: Sasha Vasko <sasha aftercode net>
- To: Olivier Chapuis <olivier chapuis free fr>
- Cc: wm-spec-list gnome org
- Subject: Re: pseudo transparency
- Date: Fri, 11 Jan 2002 10:16:48 -0600
Olivier Chapuis wrote:
There is two methods that an application can use to achieve
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
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
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
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)
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.
] [Thread Prev