plasma and new shadow mess

[Martin Gräßlin]

On Monday 07 January 2013 10:51:11 Aaron J. Seigo wrote:
> On Sunday, January 6, 2013 17:40:42 Thomas Lübking wrote:
> > 1. it will make kwin link generic-shell what is sematically the
> > gnome/unity
> > shell approach.
> 
> it is a library. that does not rely on the desktop (or other) shell. it
> provides shared functionality for applications in kde-workspace, but without
> a guaranteed API for others (ergo no headers).
why then not in libkworkspace? If it's meant for more then just the desktop 
shells the name sounds confusing.
> 
> so, no, it is not at all the same approach as gnome/unity. at all.
> 
> > 2. it will visually break non-plasma QMLs (so virtually
> > they're no longer supported, see Martins concern in [1])
> 
> ???
> 
> which QML are you thinking of that is "non-plasma"? what are they doing
> using Plasma's SVG theming?
I think it was bad worded by Thomas as it's actually a Plasma which would get 
broken: the window strip of Plasma Active.

But: we make it possible to load any Qml styled window switcher theme. There 
is no requirement to use Plasma Components, it's just a Qml file that gets 
loaded. If a user wants to have a KDE 3 style all grey that's possible. If we 
enforce Plasma that's no longer possible and if there is someone who uses that 
already it gets broken if we require the shadows. That's exactly the concern 
mentioned in the review request.
> 
> > Notice that this is a dead stupid and cumbersome way to do things [2], but
> 
> ...
> 
> > [2] Instead of dumb copying the shadow implementation of plasma we could
> > maybe rather just load the Plasma::Svg and hand over the pixmap(id)
> > internally to the Shadow system - less tested, though, but could be then
> > also easily extended to proper QML/Component shadow support, thus not
> > pointless either.
> 
> handing over the pixmap id intenrally to the shadow system is exactly what
> we do in plasma. granted, it is outside of kwin and we're doing this with
> an xatom ... but this is precisely how plasma is doing it now: we rely on
> kwin (or another window manager) to paint the shadows using pixmaps we hand
> over by id.
Yeah well, I don't want a roundtrip to X just to set an information which we 
have internally already available. For KWin we need a better approach.

Btw. for the use case of the window switcher the approach of setting the 
shadow is a performance regression. It's actually for everything inside KWin 
(and Plasma) a performance regression.

The shadow system has been designed to work around the problem which occurs if 
we try to have the shadow in the panel. That is for any window where the 
shadow should not be part of the window geometry. It makes sense for the 
panel, for KRunner and the Oxygen menus.

This approach comes with an additional rendering cost inside KWin. We need to 
create textures from multiple pixmaps, we don't have the window as a 
consistent texture any more (causes rendering glitches with various effects) 
and we need several rendering passes - one for the shadow, one for the window. 
The cost for rendering is higher from throughput to graphics card and from 
memory consumption (both GPU and X).

In the case of TabBox or anything else in KWin (and also for most things in 
Plasma like tooltips, extenders) we don't have the requirement that the 
shadows may not be part of the window geometry as it just does not matter. So 
we get the disadvantage without any advantage.

Oh and the fact that the window is one texture instead of multiple is the only 
valid argument for Client Side Window Decorations and has been the only 
argument presented by Kristian Hogsberg in his Wayland presentation on XDC. 
And you know what? I have to agree in that point.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130107/0d4e4c60/attachment.sig>