Re: pseudo transparency

Olivier Chapuis wrote:

On Fri, Jan 11, 2002 at 10:16:48AM -0600, Sasha Vasko wrote:


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.

The _NET_SUPPORTED atom indicate which _NET_WM_STATE states the wm
can support. So just adding _NET_WM_STATE_PARENTRELATIVE_BACKGROUND to
the list of the net wm state will provide the information needed.

Nope, that won't work. when atom is not in _NET_SUPPORTED it only means that window manager does not know how to set frame to ParentRelative for windows that desire it. Typical fall back in that case on the part of the app will be to try and set frame's background themselves. What we need is the property that would tell apps to stay away from messing with frame's background altogether. Something like:

About the E method. Here there is a de facto standard which
uses the ESETROOT_PMAP_ID and the _XROOTPMAP_ID atoms. Maybe,


The more flexible approach would be to use X Selections. WM-client protocol in this case would be something like :


Do you think such (interesting) methods would be fast enough
to allow window move?

It will no be slower and maybe even faster then what E method. But thing is that you don't want windows to referesh their background too often. It adds way too much CPU load, and slows down interactive actions to a crawl. CPU load will be similar in both cases, but since what I propose allows for root image to be already in clients memory - you avoid additional processing involved in transfering XImage from Pixmap in order to be tinted.

This method does something more important - it protects shared resource from possible misuse by the apps. For example with E method, app may go and destroy root pixmap, causing everything else to die horrible death.

In fact my comment on the E method was just a query:
I think that we need something that allows the wm and
applications to know when a set root program change the
background (as monitoring the _XROOTPMAP_ID) and this
independently of the transparency method used.

E method generates tons of PropertyNotify messages and apps wake up regardless of their need for Root background. With the selections approach you can send messages only to apps that are interested in root background.



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