[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: New Shadow System
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2011-01-27 17:22:24
Message-ID: op.vpy87l1j9bmiid () localhost ! localdomain
[Download RAW message or body]

Am 27.01.2011, 14:19 Uhr, schrieb Hugo Pereira Da Costa  
<hugo@oxygen-icons.org>:

> Interesting.
>
> I was following a different path on my side, namely pass the pixmaps the  
> same way as icons are passed to the _NET_WM_ICON. (that is: the entire  
> pixmap data are passed, and not the X11 handle).

Bespin shares pixmaps for client and deco this way, just have a look - you  
know the code ;-)
(there's even a simplifying class, but I pass XRender Pictures, Pixmaps  
are however no different)

The icon way is _horribly_ slow, but you're very right about the tricky  
part which is the lifetime of the
Pixmap - if you just create it from a client, it will be gone with the  
client process, so either
_every_ client would have to provide it (shared between clients of the  
same process) or kwin
has to create and keep the pixmaps and the client gets the handle and  
creates the pixmap on it.
This would however not survive a kwin restart.

Afaik the only way to directly assign a pixmap to a (root) window is  
XSetWindowBackgroundPixmap,
but that cannot be used since it provides only one pixmap (ok, one could  
handle this like a texture set)
and is (in our case) the visible rootwindow background (what is the  
wallpaper for desktopwindow free
sessions and also used by clients like conky for faked translucency ->  
we'll get bug reports for abusing
this =)

Altogether i'm not really convinced about clients passing shadow pixmaps  
onto the root window (that's
free space, everybody can -accidentally- kill those pixmaps anytime) and  
still believe that it should be
enough for the clients to share some lightmodel parameters (direction,  
strength, maybe fuzzyness) and
keep the shadow generation and pixmaps/textures in kwin which can then  
perform presence/sanity checks
and use fallbacks/defaults instead of running into BadPixmap errors...


Thomas
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]