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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
