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

List:       kwin
Subject:    Re: New Shadow System
From:       Martin =?iso-8859-1?q?Gr=E4=DFlin?= <kde () martin-graesslin ! com>
Date:       2011-01-27 20:04:40
Message-ID: 201101272104.47802.kde () martin-graesslin ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 27 January 2011 18:22:24 Thomas Lübking wrote:
> 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.
Given that we don't expect the shadows to be changed often (once in the 
lifetime) I think the slowness is no problem. Passing the handle seems 
dangerous to me and the advantage of the damage events is rather low. 
Nevertheless it might be a good solution in case we want different shadows per 
window.
> 
> 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 =)
Yes, definately not a good idea to paint on the root window.
> 
> 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...
I don't know if such generic ways would fit the needs of the toolkits. Hugo 
and Craig: please comment on what suits your needs better.

Cheers
Martin

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]