Re: pseudo transparency

[Sasha Vasko <sasha aftercode net>]

Olivier Chapuis wrote:

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

<snip>

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


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

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


<snip>

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


<snip>


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

> Olivier


Sasha