Re: pseudo transparency

On Fri, Jan 11, 2002 at 10:16:48AM -0600, Sasha Vasko wrote:
> 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.

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.

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

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

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.


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