[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:39:44
Message-ID: 201101272139.44581.hugo () oxygen-icons ! org
[Download RAW message or body]

On Thursday 27 January 2011 21:24:08 Hugo Pereira Da Costa wrote:
> 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.
> > 
> > > 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.
> 
> I'd rather leave the implementation to the style.
> For oxygen, Nuno's spent a great deal of time to define the shadow (which I
> personally love). It has three gaussians superimposed that translate
> differently when you add offsets. I don't think a generic solution could
> (nor should) honor this kind of design.
> 

Correction :)
Its actually two gaussians and a parabola.

> On top of that, for the glow, we use two colors :)
> 
> > 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]