Optimizing KWin 4.8

Since KDE SC is actually in feature freeze I thought it might be a good idea to blog about my contributions to KWin 4.8. As some of you may have noticed it is also my first post to this blog and especially to planetKDE :)

Many of my commits have been optimizing the existing code base, so despite the hopefully increased performance you should not see any changes. Or in other words: this will be a more technical blog post.

Occlusion Culling in KWin

All this started with Martin pointing me to the fact that kwin initially did not process XDamage events window specific, as they are reported by the X server, but rather gathering all events and then updating the corresponding screen region. This could lead to the strange behavior that although your current virtual desktop was empty kwin was busy repainting the background again and again, just because on another virtual desktop your videoplayer was running maximized. Clearly this is a waste of resources.

So the solution was to process the events on a per window basis, which required to change two of the main functions in KWin: paintGenericScreen and paintSimpleScreen. Now one has to know that if the screen gets repainted either one of those functions gets called no matter whether you use OpenGL or XRender for compositing. As a nice side effect this also means that the optimizations described here equally apply to the XRender backend.

  • paintGenericScreen is the general implementation which just draws the window stack bottom to top, doing the preprocessing and the rendering in the same pass. This has the advantage that you can draw every scene, but with the cost that it is not really optimized. Especially fullscreen effects use this code path.
  • paintSimpleScreen is restricted to cases where no window is transformed by an effect. The actual rendering is done in three passes. The first one is the preprocessing pass, where all effects not only get informed about what will be painted but also have the opportunity to change this data (e.g. making the window transparent). The second pass then starts drawing all the opaque windows top to bottom. At last the third pass paints all the remaining translucent parts bottom to top. The most crucial point here is to do a proper clipping when splitting up the rendering process into two passes.

While changing paintGenericScreen was straightforward by just accumulating the damage bottom to top, changing paintSimpleScreen needed a bit more work because of the aforementioned clipping. More precisely in the top to bottom pass one has to gather all the damaged translucent regions while cutting off all the regions that have already been rendered. The last pass then just has to render the remaining damaged translucent area. Or summarized one can say that kwin now implements some kind of occlusion culling.

Blur effect

Nearly everybody who asks in a KDE related chat, why KWin is performing poorly, gets the recommendation to deactivate the blur effect. The good news is that this should no longer be the case in KWin 4.8 :)

The main reason for the poor performance was that the blur effect requires the windows to be painted bottom to top and as such was limited to the unoptimized paintGenericScreen. So in KWin 4.7 not a single frame is painted with paintSimpleScreen if the blur effect is used. Hence my first objective was to port the blur effect to use paintSimpleScreen. Fortunately kwin allows the effects not only to change the painting region in the preprocessing pass but also the clipping area. This way the blur effect can now mimic the paintGenericScreen behavior and control which regions of the screen get painted bottom to top.

But just porting to paintSimpleScreen still was not that satisfactory, mainly because the blur effect still suffered from something I would call an avalanche effect. This was due to the fact that once the blurry region was damaged we had to repaint the whole region, such that a small damaged region could lead to a big repaint event (e.g. a damaged system tray icon forcing KWin to repaint the entire system tray). KWin now avoids this by buffering the blurred background in a texture, which then gets updated partially.

That’s it. :) Last but not least I want to thank Martin Gräßlin, Fredrik Höglund and Thomas Lübking for fruitful discussions and especially for taking the time to review all these changes.

16 thoughts on “Optimizing KWin 4.8

    • Just reduce the number of lines displayed in top ;-) Seriously I just checked for myself and while I am typing this Firefox is top with 10 % while kwin is not even in the top five and behind X. So looks good :-)

      • Check “CPU Time” in “System Monitor” instead. For me it is

        Xorg 156:32
        Kwin 86:19
        plasma-desktop 29:40
        Java 8:31 (for a long running java-program)
        All others have below 0:36.

        Check after a few hours’ worth of working!

  1. “Nearly everybody who asks in a KDE related chat, why KWin is performing poorly, gets the recommendation to deactivate the blur effect. The good news is that this should no longer be the case”

    I’m looking forward to validating that. Ever since the blur effect was introduced to be used by default (4.4 or so), the ‘no more necessary to manually disable blur’ claim was actually made multiple times and at least in my setup never turned out to be true. *holding thumbs*

    • I have been using Oxygen Translucent with blur enabled on a two screen setup (with one screen being a full-hd screen) for the last few weeks and there is on my r600 based card no noticeable impact due to everything being blurred. Even on the r300 it was useable.

      Up to now our statement was that we do not support Oxygen Translucent at all due to the performance impact of blur.

      Btw. we introduced Blur with 4.5 :-0

      • You introduced blur much before than 4.5 ;). The fact that it was buggy as hell doesn’t mean it wasn’t introduced…

        • ok, to be precise we had a version in 4.0 which got removed with 4.3 and a new implementation got added again in 4.5. If I talk of blur I only mean the one of 4.5 and after. The one before did not work on any driver except the NVIDIA blob anyway.

  2. KDE really needs people doing the hard thankless jobs. Performance has been bad for too long.
    So thanks for that!

  3. Pingback: Recopilación de enlaces de interés. 52ª Semana de 2011 : KDE Blog

  4. Nice, thanks so much for your hard work. When are we getting KDE with Wayland?

    • Just speaking of support for Wayland clients in KWin, there is still quite some work to be done. The even more advanced goal of reaching a X-less KWin is far away, mostly due to the fact that KWin as a window manager is more entangled with X than an average KDE application.

Comments are closed.