This week in KWin (2012, week 36)

Between writing about game performance benchmarks I also have to publish the report on the activity last week in KWin development.

The major issue this week has been an issue introduced in KWin 4.9.1. Under certain circumstances it was possible that KWin completely froze. From the perspective of a compositor that is the worst bug you can think of. I’m very sorry for introducing this issue and want to apology for any inconveniences.

Luckily the bug report hit us about release time and we were able to notify the packagers the same day and provide a fix for the issues the next day. In best case most distributions have never provided the faulty package to their users.

Apart from that as a reader of my blog you probably already know what happened this week. Some nice performance improvements hit 4.9.2 and 4.10.

Summary

Crash Fixes

Critical Bug Fixes

306260: KWin freezes when navigating between windows
This change will be available in version 4.9.2
Git Commit

Bug Fixes

293044: Kwin + opengl compositing make firefox scrolling jerky.
306457: m_vBlankTime in Options is not initialized
This change will be available in version 4.9.2
Git Commit
306262: Translucency Effect needs isActive() implementation
This change will be available in version 4.9.2
Git Commit
306225: workspace.displayHeight is wrong
This change will be available in version 4.9.2
Git Commit
306263: Animations in Translucency Effect are not working
This change will be available in version 4.9.2
Git Commit
306449: transparency bug in active window
Git Commit

New Features

303756: Allow Scripts to add menus to useractions menu
This change will be available in version 4.10
Git Commit

Tasks

306384: Toplevel::windowType() needs performance improvements
This change will be available in version 4.10
Git Commit
306383: Toplevel::windowType() contains superfluous hacks
This change will be available in version 4.9.2
Git Commit

9. September 20129. September 2012

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.

8. September 2012

Why I don’t like game rendering performance benchmarks

It’s benchmark season again and as I have raised some concerns about the results of the published benchmark, I was asked to properly explain my concerns without making it look like a rant. So this is what I try with this blog post.

Given the results of the published benchmark, I could go “Wooohooo, KWin’s the fastest!”, but instead I raise concerns. I don’t see that in the data and I hope nobody else sees that in the published data.

First a little bit about my background. After finishing my computer science studies I have been working the last two and a half years in a research department, not as a researcher, but as a developer to support research. Our main tasks are to store and manage scientific results that is experimental data.

You cannot work for more than two years in research without having that influence how you see such data. For me a benchmark is very similar to a scientific experiment.

First you have a hypothesis you come up with (e.g. “Compositing on X11 influences the game rendering performance”), then you start to setup an experiment to prove your hypothesis (e.g. “running PTS on various hardware and distributions”), then you run your experiment multiple times to have statistically relevant data and last but not least you validate your gathered results and go back to step one if something doesn’t fit. All these steps must be properly documented, so that others can reproduce the results. Being able to reproduce the results is most important.

If you don’t follow these steps your experiment/benchmark is not useful to show anything. And then you should not publish it. I’m personally not a fan of the attitude of science to not publish failure, but you should at least make clear that your setup has failures.

Now I want to assume that the published benchmark is a “paper” and that I would have the task to review it.

The first thing I would point out is that the gathered data is not statistically relevant. It is not clear how the environment influenced the results. The benchmark has been performed only on a “Ubuntu 12.10 development snaphot” on one Core i7 “Ivy Bridge” system. This means we don’t know whether the fact that it is a development snapshot has any influence on the result. Maybe there are debug builds? Maybe temporary changed defaults? Also it’s testing unreleased software (e.g. Compiz) against released software (e.g. KWin). So here we have multiple flaws in the experimental setup:

Only one operating system
Only one hardware used
Comparing software in different development stages

Also the fact that it uses an “Ubuntu 12.10 development snapshot” means that one cannot reproduce the results independently as one doesn’t know the exact state of the software in use.

I want to further stress the point of the operating system. I think this is in fact the major flaw of the setup. Looking at e.g. the performance improvements of OpenSUSE 12.2 due to switching the toolchain that is something which can quite influence the results. So we don’t know whether Ubuntu is good or bad to do such benchmarks, we just don’t know. It would have needed to run the benchmark on multiple distributions to perform the same results (yes obviously that’s not possible as Compiz only exists for Ubuntu). Especially for the tests of GNOME Shell this is relevant as Ubuntu is focusing only on Compiz and one doesn’t know how that influences the performance of other systems. Also in general the desktop environments are tested here, but hardly any distribution ships a pure KDE SC version. They all do adjustments, changing settings and so on. One has to gather enough data to ensure that the results are not becoming faulty.

The point of the multiple hardware is of course obvious. The differences between hardware are too large to not be considered. A computer is a highly complex system, an operating system a highly non-deterministic system where changing one piece can have quite some influence. Maybe the Intel drivers are just not suited for gaming, I don’t know and the benchmark neither.

Now let’s move forward and have a look at the individual experiments. The first thing which strikes me is that the standard deviation is missing. This tells me quite a lot about the experimental setup. Given that it doesn’t tell how often the experiment was run (that is how many data sets go into one graph) and the standard deviation not being provided, I assume that the experiment was just run once. This would mean that the experiment is completely flawed and that the gathered data does not provide any statistical significance. If it were a paper I would stop the review here and notify the editor. Just think about Nepomuk starting in the background to index your files while you run the benchmark or the package manager starting to update your system. This would have quite some influence on your result, but you cannot be sure that this happened in the given data.

But let’s assume I continue with looking at the data. Now I think back of the hypothesis we have and I notice that while we have quite some data sets on the influence of desktop environments on the game rendering performance, one important data set is missing: the control. For the given hypothesis only one control can be thought of: running just an X-Server without any desktop environment and run the test there. This would be a very good control as it ensures that there is no overhead introduced by any desktop environment. But it’s missing. Again if I would review this as a paper I would stop here and notify the editor.

Let’s continue nevertheless. I now want to pick out the data for Nexuiz v2.5.2 on resolution 1920×1080. The values are in the range of 9.73 fps (KWin) and 12.79 fps (KWin with unredirection). The latter value is quite higher than the others, so let’s look at the second best: 10.15 fps (LXDE). So we have results of 10 fps vs. 10 fps vs. 10 fps vs 10 fps. Now I’m not a gamer, but I would not want to play a game at 10 fps. For me the result of this specific experiment does not show any difference in the various systems, but just that the hardware is not capable of playing such a game.

At this point I want to stop the analysis of this benchmark. I think it is clear that the this benchmark does not “Prove Ubuntu Unity Very Slow to KDE, GNOME, Xfce, LXDE”, heck that tile is so wrong that I don’t know where to start with. There is no “prove” and there is nothing which shows it to be slow, just look at the example given above: the difference between the frames per seconds is in the non noticeable area. Furthermore it’s just about game rendering performance and only on the one system using a pre-release of Ubuntu. So maybe as a title “Benchmark on a development snapshot of Ubuntu 12.10 shows Unity to slow down game rendering performance on an Intel Ivy Bridge compared to KDE, GNOME, XFCE, LXDE”, yes not very catchy I agree 🙂

My point here is that this doesn’t prove anything and I care about that, because given the methodology of these benchmarks it’s quite likely that the next time a benchmark is published it “proves” KDE to be slowest and then FUD is spread about KDE just like when there was a benchmark “proving” that KDE uses more RAM. You are in a much better position to highlight the flaws of the benchmarks if you are the “winner” of the benchmark, otherwise people tell you that you are in the “denial” stage.

Maybe the most sane approach to handle these benchmarks is to detect the PTS in KWin and to go to benchmark mode, just like games. I have to think about that.

7. September 20127. September 2012

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.

7. September 20127. September 2012

Never forget your users or extending the User Actions Menu by KWin Scripts

KWin’s userbase is quite diverse. We have users being in the range from the absolute Computer beginner to the Kernel hacker. Such a diverese user base can be quite challenging for the development. On the one hand you need to keep the UI as simple as possible so that even not so experienced users can use the computer without problems. On the other hand you should not dumb down the application to not upset your very vocal Kernel hackers. There is always the tempation to have the user interface too complex given that one as a developer is an advanced user and does not really see the needs of a normal user.

In the case of KWin we are in the lucky (or unlucky) situation that our target user group should not even know that an application called “KWin” exists. The only user visible place where the name “KWin” is written is the crash dialog – and I do hope that a normal user never sees that one 😉 Of course that means that we never get bug reports or feature suggestions from “normal” users. This means we have to look at each suggested feature and each extension with the thought about our primary user group. In our mission statement we clearly define that KWin should go out of the way and the user should not notice that there is a window manager. This is something to keep always in ones mind.

But nevertheless we have and want to have advanced features. In the mission statement it’s written down that KWin provides a steep learning curve for advanced features. Think for example about things like window specific rules which are not really easy to define whithout understanding of window management.

From time to time it happens that features for advanced users are in direct conflict with our goals and what our primary user group needs. An example for that is the menu to change the window’s opacity in the window decoration menu. To be honest: it’s a quite geeky feature and soooo 200* (look what we can do: translucent windows!). It’s almost an embarrassing feature as it changes the complete window to being translucent instead of adjusting just the background. Not only is this feature quite geeky, it also clutters an already cluttered menu even more.

Based on that the menu got removed after some discussion a few releases ago, but we acknowledged the need of the experienced users and added shortcuts and mouse action support to the window decoration for changing the opacity. So we removed one way at a user visible place and replaced it with several ways to alter the opacity.

Nevertheless over the time I have seen a few complaints about the removal of the feature and it made me think what we can do about it. Of course we don’t want to bring it back, but we also don’t want to anger our advanced users. Since 4.9 we have the wonderful possibility to have scripts and so I decided to extend the scripting support to allow adding entries to it from scripts.

This means since todays git master you can execute the following script to get your Window Opacity menu back:

registerUserActionsMenu(function (client) {
  var opacity = Math.round(client.opacity*100);
  return {
    text: "Window Opacity",
    items: [{
      text: "100 %",
      checkable: true,
      checked: opacity == 100,
      triggered: function () {
 	        client.opacity = 1.0;
      }
    }, {
      text: "75 %",
      checkable: true,
      checked: opacity == 75,
      triggered: function () {
	         client.opacity = 0.75;
      }
    }, {
      text: "50 %",
      checkable: true,
      checked: opacity == 50,
      triggered: function () {
	        client.opacity = 0.5;
      }
    }, {
      text: "25 %",
      checkable: true,
      checked: opacity == 25,
      triggered: function () {
	         client.opacity = 0.25;
      }
    }, {
      text: "10 %",
      checkable: true,
      checked: opacity == 10,
      triggered: function () {
	         client.opacity = 0.1;
      }
    }
    ]
  };
})

I intend to make this script part of 4.10, but before I can do so we need i18n support inside the scripts or the titles of the menus cannot be translated.

2. September 2012

This Week in KWin (2012, week 35)

In the course of this week version 4.9.1 got tagged which will be released at the beginning of next week. In preparation of this release a few more bugfixes got pushed into the 4.9 branch. Overall the 4.9.1 release will contain 24 bugfixes, four of them crash fixes. That’s quite impressive and good work, but it is also a pity, because most of these bugs could have been spotted during the beta tests. So I hope that in future more people will use the Project Neon Image to test our latest version.

Speaking of that, this week we have seen how important it is to get early feedback. My changes last week unfortunately broke KWin badly and we got the bug report for that introduced issue the next day which made it really easy to spot the erroneous commit through git bisect and helped to fix the issue in less than 24 hours after it hit master.

Summary

Crash Fixes

304881: The decoration kcm is not protected against an unloadable qml source
This change will be available in version 4.9.1
Git Commit

Critical Bug Fixes

305875: Decorations not visible
This change will be available in version 4.10
Git Commit

Bug Fixes

226881: better placement of ungrouped window
This change will be available in version 4.9.1
Git Commit
295254: Menus and tooltips are sometime displayed incompletely
This change will be available in version 4.9.1
Git Commit
305611: Bouncing cursor does not respect global icon size
This change will be available in version 4.9.1
Git Commit
304375: Zoom effect: screen image jumps when cursor is blinking
This change will be available in version 4.9.1
Git Commit
305874: Docks break showing desktop state
This change will be available in version 4.9.1
Git Commit

2. September 2012

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.