Blog: KDE KWin Miscellaneous Stuff

[menotu]

By Martin Gräßlin (graesslin) 30 April 2012 (Martin’s Blog From the land of wobbly windows)

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).

http://blog.martin-graesslin.com/blog/2012/04/improving-kwin-startup-performance/

[Just17]

Thanks 

[Archie]

Looking forward to this optimization.

[menotu]

By Martin Gräßlin (graesslin) 3 May 2012 (Martin’s Blog From the land of wobbly windows)

Profiling of KWin

In my last blog of KWin I described the improvements in the startup of KWin. Since then I did some further profiling and could improve a few effects to load resources only when needed. E.g. Present Windows effect created the texture for the window filter on startup. This is now delayed till the user starts to type which means not only about 20 msec faster startup but also less used resources in case the user does not use the filter at all. The effect (and other effects) had created this texture on creation since 4.3. Of course it’s not a long waiting time, but in multiple effects which need to be loaded at startup it sums up to a noticeable delay.

My investigations have now reached a point where I think there is hardly anything left to do for 4.9. We still have some I/O when starting up the OpenGL compositor (150 msec) as we need to load the shaders from file but this will be quite difficult to improve without a major rewrite on how the compositor startup works, which is of course not possible for 4.9 any more and I want to change the compositor startup anyway for 4.10.

Full article

[menotu]

Mebbe something to bear in mind (comment in maroon)
===================================

by skelet13 - June 11, 2012 (skeletdev.wordpress)

GSoC Color Correction in KWin week 3 report

I have continued working on my GSoC project with the goal of achieving color correction in KWin. Last week, I concentrated my efforts on splitting the painting process to get a painting pass for each screen. But, unfortunately, there were unforeseen complications. Although the modifications work fine in KWin core, they break a significant number of the effects (unlucky me, the most complicated ones).

I have spent most of the time debugging around the effects and trying to fix each one. The problem is that in most of them it is assumed that there is only one big screen (that is an aggregation of the actual screens). So, obviously, things start to break after modifying the rendering pipeline.

It has been decided that I will put that approach on hold for a while, and begin working on a simpler one, that has very little chances of breaking effects again. However, this simpler approach (based on doing the splitting very near to the actual rendering) will have a significant performance impact. But the primary objective is to have something working.

Now I am much more confident than before, since by hacking around the effects and the core painting parts, I have a much better understanding of the code.

http://skeletdev.wordpress.com/author/skelet13/

[menotu]

By Martin Gräßlin - 27 July 2012 (Martin’s Blog From the land of wobbly windows)

QML Support for Window Decorations

......................................

In the current state the decoration consists of 370 lines of QML code and I expect to need an additional 100 lines to finish the buttons (they are already functional, that is the close button closes the window) and add some of the configuration options. The same API in C++ consists of 1500 lines of code. So we do not only get fewer lines of code but also a more readable and easier to maintain codebase. For something like a window decoration a declarative approach is much better suited than the imperative C++ way of painting elements.

Overall the new QML API will provide the same powerful features as the KDecoration API, but also provides convenience functionality as KCommonDecoration, e.g. a button group taking care of laying out the decoration buttons. To make development of QML based decorations quite simple support is currently being added to Plasmate as part of the Google Summer of Code project. So you will be able to design and also test the decoration directly from inside Plasmate. This is also quite some improvement as with C++ the only way to test a decoration is to use it in KWin, which can be quite nasty during development.

The API will need some more love till I’m quite confident to provide it’s usage but there is enough time till 4.10 :-) So I hope that we can provide a better decoration experience in 4.10. I have a few ideas concerning the usage of QML based decorations in KWin and are looking forward to experiment with them.

Full blog

[menotu]

By Martin Gräßlin - 30 August 2012 (Martin’s Blog From the land of wobbly windows)

Refactoring KWin’s Workspace

http://blog.martin-graesslin.com/blog/2012/08/refactoring-kwins-workspace/comment-page-1/#comment-50291

[menotu]

By Martin Gräßlin - 31 August 2012 (Martin’s Blog From the land of wobbly windows)

Build Instructions for KWin

On poular request I added a section on  How to Build KWin  to our Wiki. This aims to those who want to work on KWin but do not want to build all the dependencies and the other parts of the Plasma Workspaces.

I hope this can help some people to test and develop on KWin. In case you find any errors in the instructions, please let me know. I tested the instructions yesterday on my Pandaboard and it compiled KWin master against a dev environment of another distro 12.04, so they seem to be correct

http://blog.martin-graesslin.com/blog/2012/08/build-instructions-for-kwin/

[menotu]

By Martin Gräßlin - 2 September 2012 (Martin’s Blog From the land of wobbly windows)

Help KWin to revamp the configuration interfaces

The configuration interfaces of KWin in System Settings are really old. Some of them date back to KDE 1 times (copyright of 1997) when the window manager was KWM. This has some implications about the code: all the used widgets are configured through C++ which makes it very difficult to maintain and develop the configuration modules. The user interfaces do not yet use UI files which could be easily edited with  Qt Designer. That’s the main reason why the interfaces still look like they used to be in KDE 1 and 2 times.

I think it’s about time to overcome the “uuuuhh, I don’t want to touch that code” state and start to move forward. For this it would require to transform the user interfaces into UI files. This is a very easy task which does not require any programming skills. And that’s why I blog about it. This would be a great task for anyone who always wanted to contribute to KDE, but has not dared because he is not a programmer.

All it needs is to go to System Settings -> Window Behavior -> Window Behavior and create for each tab a widget in Qt Designer which looks exactly like it used to be. If we have that it’s becoming easier for us developers to extend it, to try out better interfaces without touching the code. In case you have any questions feel free to send me a mail, contact me on IRC or leave a comment on this blog.

http://blog.martin-graesslin.com/blog/2012/09/help-kwin-to-revamp-the-configuration-interfaces/

[menotu]

By Martin Gräßlin - 7 September 2012 (Martin’s Blog From the land of wobbly windows)

Performance Improvements in KWin 4.9.2 and 4.10

Recently I did some refactoring around the Compositor and there was one change where Thomas was afraid that this would cause a performance regression. So I used Valgrind’s callgrind tool to verify if this is true. And yes the code had a slight performance drop, though it is luckily not in the hot code path and even if the overhead would be rather small.

But having the callgrind log I looked a little bit closer into it, which I haven’t done since the last optimization for I think 4.8. Since that is quite some time ago and I had basically forgotten how it looked like back then, I was shocked about a few results. So I knew that in the last optimization I adjusted all effects to be not active by default except the translucency (and blur) effect.

Now looking at the results I saw that the translucency effect is rather expensive and that by default the effect is not doing anything unless you are moving windows. This is of course a rather unpleasant behavior to have an expensive effect doing nothing. So I looked at the implementation and found a way to better track when the effect should be active. Unless you have enabled the effect to set decorations or inactive windows to translucent the effect is now disabled by default. Just when you start moving a window the effect gets active. And even then the effect performs better.

But there was more into it. So I noticed that there is supposed to be an animation when a window starts to move, but personally I have never seen it. Looking closer at the code I noticed that this could have never worked. I decided that an animation added to 4.1 which has never worked can be dropped which again improves a little bit the performance. We might add a better translucency effect for 4.10 which adds the animation again, but for 4.9.x there is no user visible change by removing the animation.

But still I could not fully understand why the effect is so expensive, all it does is checking the type of the window multiple times: is it a desktop? is it a dialog? and so on. That cannot be that expensive, but it is. I tracked down the expensive call in KCacheGrind and found that the check for the windowType() is expensive.

The code had quite some surprises. It gets the window type, calls the window rules to have user specific overwrites and some hacks to fix some special windows. One of the hacks was to make menus with a certain size being a top menu. This hack must have been for the time when the top menu had not yet been implemented as a kicker applet. Not only is it unlikely that anybody is using such a combination of KWin and old KDE versions also KWin has not supported the top menu at all in any 4.x release and the code got dropped a few releases ago. Which allowed us to savely remove that part.

The second hack is even more intersting. It is a workaround for a dialog in OpenOffice.org 1.x added in 2003. For this hack each time the method was called a complete string comparison had to be done in case the window is a dialog. Again the hack was quite outdated given that on a modern system you don’t have any windows with the name openoffice, but only libreoffice. Also I searched through the LibreOffice help to find the dialog in question and verified the window type: the hack is no longer required. Both hacks are removed for 4.9.2. The lesson to be learnt from that: never add hacks to your application, they stay. In general I would not accept workarounds for applications inside KWin anymore. This clearly belongs to the area of window specific rules and scripts.

But the main optimization of this method will be available in 4.10. The output of callgrind showed that this method was causing quite some expensive dynamic casts. In fact each call caused two dynamic casts to check whether it is a specific sub class and basically the method contained two interwoven implementations for the two specific sub classes. The logical step was to make the method pure virtual and implement it in the sub classes. According to the callgrind logs after the change this improves the performance quite a lot (I cannot say whether this can be noticed by a user, for this it might be too small, but it should be noticable on the battery). Given that this is not just dropping of hacks but a refactoring it cannot go into 4.9.2 as there is still the risk of a regression.

Interestingly when the method got implemented the approach was correct and also not expensive. From within the window manager code path it gets only called very few times, in my dataset it’s about 10 % of the calls coming from the window manager and it seems like most often to be called when a window gets added, so on a longer running session the amount would be even smaller. The code got expensive when it became to be used from within the effects system which is compared to the window manager a rather hot code path. Which is also something important to remember when optimizing: check whether the expected methods are in the hot path. This is now the case for KWin: the most expensive call is the one to render a window, the second most expensive the one which starts the rendering of a frame. And for those I’m already working on further optimizations for 4.10.

http://blog.martin-graesslin.com/blog/2012/09/performance-improvements-in-kwin-4-9-2-and-4-10/

[menotu]

By Martin Gräßlin - 9 September 2012 (Martin’s Blog From the land of wobbly windows)

Help KWin to maintain the Effect Configurations

Last week I asked for help for some non coding tasks and I was positively surprised by the feedback. Thanks a lot, this community just rocks. By the way there are always possibilities to contribute to KDE, for example we are still looking for about 5,000 EUR to finance the very important Randa Sprint.

Given the great result of last weeks experiment I decided to try to setup another task again. This time I want to ensure that people do not work on the same tasks, so I setup a  project wiki page to claim the task one is working on.

So what is it about: the configuration interfaces of the KWin Effects are written more or less manually. That is the logic to load, save, set to default of configuration values is written in the code. But KDE supports a great framework called KConfigXT which does all of this automatically. All it needs is to describe the configuration options in an XML file containing the name of an option, the type and the default value. All these information are already present in the current implementation. So it’s just taking the values and bringing them into another format.

The advantage is that we can use that XML description to generate code to be used in the Effect and the configuration. This ensures that typos do not introduce bugs, but also it removes quite some boilerplate code copied in each configuration module. Last but not least it allows us to think about new ways to do the configuration if we ever want to.

So please grab one of the 22 remaining effects to port. I already did the port of the Translucency Effect as an example on how to do it. It’s really not a difficult task and it is very important for the maintenance of KWin. The wiki page includes detailed instructions on how to perform such a task.

http://blog.martin-graesslin.com/blog/2012/09/help-kwin-to-maintain-the-effect-configurations/comment-page-1/#comment-50634

[menotu]

By Martin Gräßlin - 21 September 2012 (Martin’s Blog From the land of wobbly windows)

A real update on the progress of Wayland in KWin and KDE

Of course I was asked quite often about the current state of Wayland in KDE and I honestly replied which resulted in rather incorrect “news” postings about Wayland in KDE not happening “any time soon” (whatever that is supposed to mean) to “Wayland for KDE will be delayed” (given that we never had a schedule in the first place, it cannot be delayed).

So I want to give here a general overview of all the things which need to be done for Wayland.
Porting KDE to Wayland

For a general “KDE on Wayland” we have to consider three areas:

    Applications
    Desktop Shell
    Compositor

For those we have different things which needs to be done and so I will discuss them separately.

KDE Applications on Wayland

For most KDE Applications there is not much work to be done. Thanks to the Windows and OS X ports the code is no longer platform dependent, so all which is needed is having a Wayland backend instead of an X11 backend.

This problem is solved with Qt 5. Once our applications use Qt 5 and KDE Frameworks 5 they should run fine on any Wayland compositor, e.g. Weston. Of course there are a few applications which use X11 directly (e.g. ksnapshot), those needs to be adjusted in addition or be morphed into KDE’s Wayland Compositor (that is something I expect to happen with tools like ksnapshot or klipper).

KDE Plasma

Our Plasma Desktop Shells (Desktop/Netbook/Device) need more adjustments than a normal KDE Application. Plasma is still doing quite some X11 directly for various tasks, like e.g. the tasks manager or pretty much any communication with KWin.

Before we can start working on adjusting Plasma for Wayland we need to get it to Qt 5 first and that requires KDE Frameworks 5 and that requires libplasma2. Currently our Plasma hackers are meeting in Randa thanks to your support to work on libplasma2.

Once Plasma is running on top of libplasma2 we can start working on Wayland support.

But what is really important is that we Do not want to break the desktop.

Neither with going to libplasma2 nor with going to Wayland. So any fast steps do not make any sense. It’s important to get this right before giving it to the users. Wayland is an awesome technology, we all want it, we all support it and we don’t want to damage the technology by going to it too early.

This has happened too often in the past (not only in KDE) that great technology got damaged because it got released too early on the users. (NOTE: with this I do not mean that Wayland is not ready yet, but that going to Wayland will cause regressions inside Plasma/KWin and there is no need to expose these to the users if we have a wonderfully working X11 backend.)

KWin

Our current planning is to make KWin our Wayland Compositor. This seems like a useful approach as that can help us having a consistent window management experience no matter whether you run on X11 or on Wayland. Even in a Wayland world we will still need to support X11, it’s not like that will go away. I expect that the Linux world will have to support X11 at least for the next 25 years, we have many legacy applications around, which still use things like Motif, so that won’t change. We have with KWin a very good X11 based window manager so it seems quite logical to me that also in a Wayland world KWin will be responsible for being the X11 based window manager.

Full blog

[menotu]

By Martin Gräßlin - 29 September 2012 (Martin’s Blog From the land of wobbly windows)

Who needs GLX? KWin does not

I’m very excited about a change I have been working on for KWin since yesterday and which has entered the review process today. The result of it can be seen in this debug output of KWin (see bottom link)

Everything looks quite normal. OpenGL 2 based compositing, everything works fine, all effects load. But still there is something very exciting going on. Instead of GLX, the EGL backend is used, which has been written for the OpenGL ES 2.0 compositor. But this is the normal KWin, not the kwin_gles.

We run OpenGL over EGL. To do so the current patch uses an environment variable KWIN_OPENGL_WS which can be set to egl. By default we still use GLX as that’s the safest what we can get at the moment with the available driver collection (and our egl backend needs some more love to be honest). It shows how important the refactoring which I have blogged about last week has been: without it this change would not have been possible.

This is a very exciting change as it means we have one backend to serve both OpenGL and OpenGL ES 2.0, it is also very exciting as it means that KWin is already prepared for the proposed new OpenGL ABI, which will deprecate GLX.

The current OpenGL ABI pulls in GLX even if you don’t want GLX at all. I’m very happy that we have this EGL backend as this can turn out to be very important for the adoption of the new OpenGL ABI. It has been noted during the discussion at XDC that there is a chicken and the egg problem by distributions not providing EGL and software therefore not using EGL which means distros do not provide EGL. We can help here as we are a component which most distributions ship and which now requires (currently still optionally) EGL.

As a free software user I’m also excited that this is a change fully built on top of the free OpenGL stack. For a long time quite some functionality of KWin had only been available with proprietary drivers. Now not only the free OpenGL stack provides all we need, it also allows us to move into areas where the proprietary drivers are not yet.  With my KWin developer hat on, I of course hope that the proprietary drivers will start to provide EGL, too.

Last but not least I am excited about this change as it is another small step on our long road through the country. It means that changes which will need to happen in the future can also be provided to the OpenGL version of KWin even if we do no longer use GLX as the primary backend.

http://blog.martin-graesslin.com/blog/2012/09/who-needs-glx-kwin-does-not/

[menotu]

By Martin Gräßlin -  6. October 2012 (Martin’s Blog From the land of wobbly windows)

[Help KWin] Document Effect Animations


Given the success of the two community involvements I recently tried with KConfigXT and UI files (both merged into master), I decided to set up regular tasks and announce them through my blog. I will mark those in the caption with [Help KWin].

And this weeks task is a no coding task, but a documentation task. It is a task which can be considered as part of the Extra Mile project.

Let me introduce to the idea: some days ago I sent a mail to the kde-artist mailing list to get help on having better animations, because somehow it doesn’t feel as smooth as other compositors, but performance is not a problem. So our animations have to be wrong (I assumed) and I wanted help from people who understand it.

Well we figured out quite fast that the actual issue is that our animations are not consistent, e.g. two fade animations don’t look the same. Now that is actually pretty easy to fix and would give a much better user experience.

But before we can do so we need to know our animations and to be honest we do not know. So I call for help! Help us document all the animations going on. This would allow us afterwards to define basic patterns for the animations.

I just created a a wiki   page to document the progress and to explain how one can find the animations even if one is not familiar with C++. While programming skills can be helpful it’s not required for this task, it’s basically just “reading text” in the browser.

http://blog.martin-graesslin.com/blog/2012/10/help-kwin-document-effect-animations/

http://blog.martin-graesslin.com/blog/2012/09/help-kwin-to-maintain-the-effect-configurations/

Extra_Mile

http://blog.martin-graesslin.com/blog/2012/09/help-kwin-to-revamp-the-configuration-interfaces/

[menotu]

By Martin Gräßlin -  7. October 2012 (Martin’s Blog From the land of wobbly windows)

KWin Hacking++

Very soon after joining the KWin development team almost five years ago, I realized that KWin would need at least one full time developer. It is one of the most important parts for the user experience of the KDE Plasma Workspaces and we have seen quite often that important changes for the user experience could not be implemented due to lack of manpower.

With the upcoming required changes like Qt 5 and Wayland the need for developers is increasing. I think it’s currently a wonderful time to join the KWin development. It’s a very interesting and challenging work and working on KWin means working on the future of the free desktop.

Lately I had more possibilities to work on KWin and starting from January I will join Blue Systems for working on KWin. I want to thank Blue Systems for this great opportunity and also for all the other sponsored work in the KDE community.

I’m really excited about this new possibility and are looking forward to it. I want to use this chance to work on bringing KWin to the world of Wayland. As explained in my blog post about the current state of development, I’m very satisfied with all the preparation work which went into KWin and I think it’s now in a state that we can start hacking on it :-) And I hope to see lots of involvement from the community. All the work will go directly into master, so it will be easy to test the new features but also easy to contribute to it. I intend to continue setting up simple tasks for the community and announce them through my blog.

http://blog.martin-graesslin.com/blog/2012/10/kwin-hacking/