Improving KWin Startup Performance

I haven’t been blogging about KWin for quite some time, so it’s way time to write what I recently worked on for KWin.

The big topic of the work of the last two weeks is improving the startup experience of KWin. It’s mostly a scratch your own itch as I do restart KWin quite often while working on it and having it start up faster is a nice thing in general.

KWin consists of multiple parts which need to startup:

  • Window Manager
  • Compositor
  • Effects
  • Scripts

The current version does everything in one go and starts with the compositor, but the first frame is rendered after everything has been set up. During this process the screen is frozen as the compositor has taken over the rendering from X and the screen has not yet been rendered by the compositor. This is not visible for users as KWin only starts up while the Splash Screen is shown and given the way how our Splash works this short freeze is hardly visible. If you know that it has to happen and if you know which of the shown icons belongs to the window manager you can see it.

My idea to improve this is splitting up the startup into phases and try to get the first frame rendered faster. E.g. the Compositor is fully functional without Effects, the Window Manager does not need the scripts and so on. What we now already have in master is delaying the loading of Scripts into the first event cycle after the Window Manager has set up everything else.

This does not shorten the startup time but reduced the frozen time. Even the overall frozen time is more or less the same, but we get a rendered frame in between.

To get the actual startup time down a possible solution is to identify areas which take long and make them load in parallel. For that areas where KWin actually waits for something else need to be identified and moved into an async running thread.

One of these areas is the loading of the configuration options. KWin re-parses the configuration file at startup. This is I/O and KWin needs to wait for it, but no longer in current master. The I/O operation is now performed in a background thread and only if the loading has not finished before KWin needs to access a configuration value for the first time it will have to wait. On my system loading the file takes only a few milliseconds and with an SSD it should be even faster, but nevertheless it’s a few milliseconds shorter startup time. And we have to consider that during startup there is a lot I/O going on and the file has probably not yet moved into the cache. But the longer it takes the more likely it is that KWin has to wait as we need config options very early in the startup process.

Also the Compositor is currently waiting: it invokes an external program to figure out whether direct rendering is supported or not. After reworking the patches multiple times during review this is now strongly improved. KWin does no longer have to wait for the external program and as a side effect the code got cleaned up, so that no OpenGL call is created outside the compositor. To achieve the we “had to” remove OpenGL detection from the Desktop Effects configuration module. It now queries KWin directly which is of course much better.

Executing the external program took around 100 msec on my system and the code which got removed were another 50 msec. That was about 5 % of the overall KWin startup time on my system.

While doing the profiling I also figured out a few things which can easily improved when creating and destroying windows. So I discovered that the window decorations are actually created twice: once when the window is started for compositing and once when the window is fully managed by the window manager. This had been required to support both compositing and non-compositing and to allow easily turning on and off compositing at runtime (decoration needs to be recreated to e.g. remove shadows). My current patches will now ensure that the decoration is not created twice when a window is opened, though in the special case when kwin restarts it still has to create them twice. But that’s a problem I have to live with and which does not affect our users.

Another interesting thing we discovered due to a crash I recently introduced: while ending the window manager completely we performed quite some heavy operations on the windows, which make sense during the normal operation but not when shutting down. This is now nicely optimized away resulting in a faster and more secure shutdown.

This weekend I continued to move I/O operations into threads and loading KWin scripts from file does no longer block the window manager and compositor. It’s now more or less a pattern which I will try to use for other areas where files are loaded (e.g. some effects).

17 thoughts on “Improving KWin Startup Performance

  1. Your blog posts are very pleasing to my eyes. When it is related to programming I love the words: Performance, Improvement, Optimization… :)
    When that is related to KDE it is even more pleasing. And you incorporate all of them.

    1. no, that is nothing were KWin makes sense as it currently needs X for compositing

  2. Hi Martin,

    Thanks for your awesome work on KWin! I thought I have been meaning to look into for ages, but never got around to: I notice that there is quite some time from the user session starts until kwin is started. I assume this is due to kwin requiring other things (such as X?) to be instantiated first. Do you have any comments on this? Would it be possible to make kwin’s startup asynchronous enough so that kwin could be started as the first process in the user session, simultaneously with X and any other dependencies?

    1. It is the first process which gets started after everything has been started to actually start KWin.

  3. Whenever I see post about performance improvements in KDE im just smiling like jackass :)

    PS Is KDE startup multithreaded/those improvements can benefit from multicore CPUs?

    Cheers.

  4. Great!!!
    Faster Kwin is a good idea, i think kde needs to boot faster, in my system kde takes more time to boot than kernel + services + X, So any work is just a good news.
    This blog is a great programming teachin tool

  5. Ah, now I know where that little freeze comes on startup. I created a QML splash screen with a continuous animation which stops for a brief amount of time, that’s when KWin starts :-) Good to know.
    What about your plans to start KWin already before login, i.e. that we have it available at KDM/LightDM already? And then have it load the respective user’s settings on login. Or is this difficult/not possible/not planned if kwin is running in a different user context? Just a thought :)

    1. I would be interested to know whether the animation is still stopping with current master. If I read my timing data correctly it should now be around ~200 msec to start the compositor which should hardly be visible in the splash screen.

  6. Nice work! Since KDE 4.7.0 the startup of the KDE desktop is much slower than in KDE 4.6.x (I notice it because on my home computer I have an old Ubuntu with KDE 4.6.x and an up-to-date Arch Linux with KDE 4.8.2 and I easily see the difference). The splash screen itself takes a few seconds to appear and when it has appeared, each of the steps is slower than in KDE 4.6.x. As KWin has become faster with each release (thank you!!!!), there must be something else that slows the startup down, but what? I have disabled nepomuk, I have disabled everything that starts akonadi at startup (including the clock), I have removed and uninstalled Lancelot (which is also slow to load and which loads even when it is not on my panel), there is almost no plasmoid on my screen. Anyway, thanks for optimizing the startup of KWin, because even in KDE 4.6 times I considered the startup of the KDE desktop too slow :-)

    1. it’s btw quite likely that the startup of KWin became worse due to the improvements in KWin. E.g. as KWin now uses OpenGL 2 it needs to read the OpenGL shaders from file.

Comments are closed.