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

List:       kwin
Subject:    Re: New Shadow System
From:       Hugo Pereira Da Costa <hugo () oxygen-icons ! org>
Date:       2011-01-27 20:25:03
Message-ID: 201101272125.03358.hugo () oxygen-icons ! org
[Download RAW message or body]

On Thursday 27 January 2011 21:04:40 Martin Gräßlin wrote:
> 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.

I agree. 
Now, the way Qt pass the icon to X, it actually provides both. The handle and 
the pixmap. 

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