The Problems with Shadows in KWin explained

[Martin Gräßlin]

Hi all,

I wanted to share/explain why the changes in Plasma Shadows caused regressions 
in (an unknown number of) KWin effects.

For this I first want to give an outline of how the compositing works. As you 
are probably aware KWin consists of a window manager and a compositor 
interacting with each other. For each window the window manager sees, it 
redirects the rendering in an off-screen pixmap which is used by the 
compositor. The pixmap has exactly the same size as the window.

When the compositor needs to render a frame it queries the window manager for 
the current stacking order of all windows and then gets from each window the 
pixmap and renders it to the screen. The compositor takes care of only 
rendering the areas which actually visually changed (got damaged). E.g. if you 
hover an icon, only the area of the icon should be repainted.

The compositor queries the window manager for the position of the window and 
renders the pixmap to the screen with the exact same geometry.

So far so good, that was the very basic without any transformations or 
additions. The compositor is in control of the complete screen and can 
manipulate the rendering. That's what we do with the shadows which got 
introduced for the Plasma Panel and window menus. There it was important to 
have the shadows not to be part of the actual window because that changes 
positioning and interaction with other windows. The compositor sees that the 
window has a shadow attached and takes care of rendering it behind the actual 
window. It knows that there is a shadow and ensures that the correct areas get 
updated and so on.

Nevertheless there have been regressions and that's in the effect system. The 
effect system is somewhere in between the window manager and the compositor. 
During rendering a frame all the windows (not the content!) are passed through 
all interested effects and they are able to transform the position and 
geometry which should end up on the screen. For example the sliding popups 
effect moves the window and performs some geometry clipping, so that it looks 
like a window is sliding out the screen edge.

With the change about the shadows some assumptions in the effects broke: 
window geometry is equal to geometry of visual representation. In the case of 
sliding popup this results in the shadows being clipped away during the 
animation and shadow garbage on the screen as wrong areas get updated.

The problem with Sliding Popups is addressed in review request 108255 [1]. It 
would be great if more people could give it a try. It's the effect which had 
shown most regressions in the past as it's actually quite difficult to get the 
clip regions right.

If you look at the diff, you can see that accesses like x(), y(), width() and 
height() on the window were used. With other words the geometry of the window. 
That used to work fine as the window geometry was equal to the geometry of the 
visual representation (also the effect is older than the shadows in KWin). Now 
with the change it broke as the calculations did not consider the shadow's 
geometry.

In the review the access is changed to "expandedGeometry()" which is the API 
hook to get the geometry plus some additional shadows. This is what needs to 
be used in all effects which need the visual representation to be the same as 
the geometry it operates on.

The good thing: since the shadows are in the window decoration for quite some 
time, most effects should be aware of it. The bad thing: we don't know which 
effects have this assumption. It could basically be every effect which is now 
affected. To be sure we actually have to test all effects whether they still 
work correctly. I still don't have an idea on how we can do the testing, but 
once I have an idea, I will share it. Given that it's about 40 effects which 
might interfere with each other plus three compositors (xrender, opengl 1, 
opengl 2) it's quite some work which I cannot handle by myself. And yeah the 
compositors need to be tested (see review comments in the mentioned request).

The lesson to be learnt from that experience is that it's better to ask once 
the KWin team whether a change which interacts with the compositor, is safe to 
go in. It doesn't cost much and we have the knowledge to say whether something 
is safe or whether we first need to do some testing. Even better would be to 
get more people into knowing how KWin works ;-)

Best Regards
Martin

[1] http://git.reviewboard.kde.org/r/108255/
-------------- 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/plasma-devel/attachments/20130109/191ab86a/attachment.sig>