Posted on

About Compositors and Game Rendering Performance

Today Phoronix published (again) test results comparing the Game Rendering Performance on various desktop environments. As it “seems” like the performance of Game Rendering under KWin got worse in comparison to last year I want to point out a few things.

First of all: keep in mind that this is a test of Game Rendering Performance and doesn’t tell anything about the performance of tasks that matter. The development focus of KWin is clearly not on being great for games. We want to be (and are) the best composited window manager for desktop systems. That is what matters that is what we fine tune the system for.

Another important fact to know is that last years test was seriously flawed and I think this years test is flawed in a similar way. Last year KWin used by default unredirection of fullscreen windows while no other composited window manager in the test did that. With 4.7 we adjusted the default and turned unredirection off. But at the same time Mutter received to my knowledge unredirection of fullscreen windows. In case it is enabled in Mutter we have the explanation for last years bad results and this years good results.

If I would perform such a test, I would not benchmark KWin once but once for OpenGL 2.x backend, once for OpenGL ES 2.0 backend, once for OpenGL 1.x backend, once for XRender backend, the same set with unredirection of fullscreen windows turned on and once without compositing at all. We see there are so many things that would influence the game rendering performance that just one run of the benchmark is not enough.

But still we would recommend to turn compositing off when playing games. At least that is what I would do. A window manager is mostly just in the way of games and that is one of the reasons why gaming on desktop is by far not as good as playing on a gaming console. So if you want to game with KWin use the feature to specify a window specific rule to block compositing as long as the game is running. This will yield the best game rendering performance.

Posted on

KWin Effects written in JavaScript

Today I cannot make such a nice announcement as Aaron yesterday, but I can at least try announce something I personally consider as awesome.

This weekend I tried to make it possible to write KWin effects in JavaScript. After about two hours of work the effect loader was adjusted to load a Qt script instead of the library written in C++. This is a quite important step for the future of effects in KWin. It finally makes it possible to share effects via Get Hot New Stuff, so that our users can download new effects directly from the control module.

For packaging effects we use the well established Plasma Package structure, so that our script developers only need to know this one common way. The API itself will share as much as possible with the KWin scripting API – of course with adjustments for effects. For animating the API is based on the AnimationEffect introduced in 4.8.

From a performance point of view using JavaScript does not change anything. Our effect system has two phases: one to react on changes in the window manager (e.g. a window got activated) and one to perform the rendering. The scripting API only interacts with the window manager, so all the rendering is still good old C++ code – a similar approach to QML.

Now I guess you want to know what you can do with it. So here I present for example a Fade like effect written in JavaScript (for comparison: C++ version is > 200 SLOC):

var duration = 250;
effects.windowAdded.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 1.0);
});
effects.windowClosed.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 0.0, 1.0);
});

For us KWin core developers the scripted effects will be an important step as well. For quite some time we have been unhappy with the fact that there are too many effects which become difficult to maintain – especially if we have to adjust the API. With effects written in JavaScript this becomes much simpler. As we do not have to keep the ABI (API compatibility is enough) stable we can move effects written in JavaScript out of the source tree and make them available for download.

At the moment the JavaScript API is just at the beginning. But I expect it to evolve over the course of the current release cycle. For me the scripts are rather important as it also provides us an easy way to have device specific adjustments.

As I wrote currently the scripts do not operate during the rendering. Because of that we don’t have bindings for WebGL. This would at the moment not make any sense. Nevertheless it might be that we allow to upload custom shaders, but I won’t pursue such a task in the 4.9 cycle.

Posted on

Create Temporary Desktops For Applications

There are applications which are more or less a mess for a window manager. For example The GIMP opens quite a lot of windows and you want to have all of those windows visible. In general you don’t want to have any other window on the same desktop

The solution to that is to move GIMP on it’s own desktop. But how? We can use static window rules to get this working, but what if there are already windows on that desktop? The perfect solution to that would be to have a desktop which gets created when you open GIMP and gets removed again when GIMP closes.

This was so far not yet possible without manual interaction. But with todays additions to KWin scripting this became possible. Here I present a KWin script which does exactly that:

workspace.clientAdded.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // create a new workspace for the Gimp image window (kind of the main window)
    // switch to the new desktop and send the gimp window to it
    workspace.desktops = workspace.desktops+1;
    workspace.currentDesktop = workspace.desktops;
    client.desktop = workspace.currentDesktop;
  } else if (client.resourceClass == "gimp-2.6") {
    // send all other gimp windows to the current desktop
    client.desktop = workspace.currentDesktop;
  }
});

workspace.clientRemoved.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // when closing the gimp window let's remove the last desktop
    workspace.desktops = workspace.desktops-1;
  }
});

I should really start to publish the quite useful example scripts I write to test the scripting functionality on places like kde-apps 🙂 The API for 4.9 is documented on Techbase

Posted on

The Importance of Mentoring

Currently the KWin team is rewriting the work of two past Google Summer of Code projects. This is of course the worst thing which can happen about the projects. In retrospection we clearly have to say that the projects actually were failures – at least for the developer community. But both students succeeded their project, so we cannot say it’s the fault of the students. On the other hand the projects had different mentors, so blaming the mentors is too easy as well.

In this blog post I want to reflect why we consider the projects after more than one (respectively two) years as failures. What did go wrong and what can be improved in future projects? I hope this can be a help for more projects than just KWin.

I will base all examples on scripting – the project I am currently rewriting. Just to give an example of the scope: when scripting got imported into trunk it consisted of 3200 SLOC and now after the rewrite is almost finished it is down to about 500 SLOC which are mostly written by me. At the same time the provided functionality increased.

Don’t expect Students to Understand Complex Code

The scripting project should make it possible to have scripts run when “something happens”. E.g. if a window gets maximized the scripts should be notified. In the Qt way the best way to achieve that is by emitting a signal. Now this is what our student did. But in all cases I found so far the signals were emitted in the wrong place. So what is wrong?

KWin core works in a way that a user action triggers a method. E.g. entering the fullScreen mode will end up in Client::setFullScreen. But this method does not just perform setting the window to fullScreen, it also evaluates first whether it is feasible to set the window to fullscreen. For example the user might have established a window specific rule to disallow this window to go fullscreen. In that case the method will not change the state of the window.

The common pattern our student introduced was to emit the signal before the method had evaluated whether the window will change the state. So the scripts are notified with potentially wrong state change information.

Of course we cannot expect that the student for whom the code is completely new will understand these concepts. If you don’t know the internals of an application the behavior is in fact unexpected especially if it is only partially documented or commented.

Given this experience it is important to give a student enough time to get familiar with the rather complex code base. In this time it is important to provide the required help. In the example above it would have been a good advice to emit the signals whenever the effects are invoked – which happens at the same place (nowadays the notification of scripting and effects are merged) through direct method invocation.

Work in master

The Scripting GSoC got implemented in an SVN branch. For me as a team member and not being the mentor it was difficult to follow the development. In the end the branch got merged into SVN trunk without a review done by the team.

Some of the issues are resolved nowadays thanks to the git migration. So even if a student works in an own branch the team mates would get the commit mails and would be able to do a post-commit review on each commit. But still working in a branch for a long time brings disadvantages. Most likely the student is disconnected from the work. The team mates might work on the same code area, making merging more difficult – especially for a young developer who also has to learn to work with a complex VCS such as git.

So I think that it is most important to have the work been done in master (or any other development branch) directly. This might be tricky as KDE SC’s release schedule does not align well with GSoC, but as soon as the release branch is created there is no reason to not work on master.

Even while master is frozen the student should follow the common pattern and propose each change as a Review Request. This gives early feedback to the student and moves the burden of mentoring to the shoulders of the complete team. The team mates know what the student is working on and can provide early help and spot potential problems even if the mentor does not spot them. Remember: it’s not your student, it’s the team’s student.

Interfere before the student runs in the wrong direction

One of the tasks of a mentor should be to provide guidance to the student and ensure that the project goes in the right direction. I remember that my mentor did exactly that at one point were I started to do fancy stuff.

In case of the scripting project the student started to implement a kind of JavaScript extension for “Lazy Logic”. This was clearly not in the scope of the project, it might have been fun to implement for the student, but it’s nothing which is needed in a window manager. That’s just the wrong place to design new language features for JavaScript.

Given that the code was undocumented and I did not find any documentation explaining how this language feature works or why I would need it and last but not least I did not understand the code, it was one of the first code parts I dropped. This would not have been needed. The student should have concentrated on the task he is proposed to do.

Remember that the world is round

Yes, there are time zones. Yes most mentors have a day job and are restricted in the time they are available. It is no help to the project if the student works while the mentor sleeps and the student has to wait a day when he needs to ask questions to continue the project.

I remember that we had one project with the student living in Mexico and the mentor living in Australia. Of course this is a rather sub optimal combination. Don’t expect that the student will adjust his sleep rhythm. Even as a GSoC student he has the right for a normal social life.

Personally I decided not to mentor a student who doesn’t live in a European timezone. I just acknowledge with that, that I am constrained in time and that also all team members live in Europe, so we just cannot mentor students living on the other side of the world.

Communicate!

Communication is in my opinion one of the central aspects for a successful projects. During the project I mentored last year I tried to discuss the state of the project each day. And with communication I do not only mean e-mail or IRC, but also phone and personal meetings. If you live close to each other it might be a good idea to meet at least once, if the student lives in Europe Akademy is a must!

But communication is not only important with the mentor. Also with the complete team. The student should subscribe to the mailing list, read and answer review requests, be present in the IRC channel. His project benefits from it and the chances are better that the student stays after noticing how great the KDE community works.

Require Documentation

No code should be merged without documentation and without unit tests (if your project uses them). There is no excuse for a young developer to not write documentation. If the student works on a new area of code it is extremely important to have everything documented in a way that any of your team members can continue working with the code.

In case of scripting the code was lacking any documentation not even a high level description of the design was provided. This made it impossible to continue to work with the project. Trying to understand undocumented code can be more difficult than rewriting from scratch.

During a GSoC project you have the chance to enforce documentation. Make it clear that the student will not pass the final evaluation if the code is not documented. Documentation is not a nice candy, but at least as important as the code itself. Undocumented code is just unacceptable in the year 2012.

Be Prepared for the Worst

The worst for the developer team is that the student stops working with the last day of GSoC. This is bad but happens. The team has to be able to take over the project. A code dump is no solution and in doubt better not merge in the project than introduce bugs and instability. Yes that means that a GSoC project was wasted but it prevents a degeneration of the code base and does not bind your teammates to fix up the code.

In case of scripting we got a code dump which was completely undocumented and basically we have never seen anything of the student again. For me it would have been easier to just write the bindings from scratch than to fix up the project. Between the end of the project and my rewrite I had to fight several times with strange things done in scripting. So overall the project costs for the core team were higher than the benefits.

Adjust the proposed projects to the fact that the student will not be around after the project. $SUPERAWESOMEFEATURE is just bit crap if it cannot be maintained by your team. Use projects were you are sure that it will benefit the team even if the student will never touch the code again.

Adjust Your Own Expectations

Many mentors try to get just “cheap” work done and have the dream to get a new team member which might some day replace their position in the team. This might happen, but is rather unlikely. If that is your aim, you might head in the wrong direction. Now I can say lots about it, but there are people who can do that better, so I recommend to read the slides by Leslie Hawthorn from this years linux.conf.au.

The KWin team has learned from the experience with our failed projects. During last years project I was holding the hand of my student. For me it was important to get good code written and not much code or have him working on new areas. Also this year I will not mentor a project which would introduce a new area in KWin. E.g. Wayland support is out of bounds for a GSoC.

Posted on

Aurorae 3: Window Decorations with QtQuick

Once upon a time there was a window decoration which was KDE’s default decoration. But years ago it fell into a deep sleep. The world changed while the decoration slept. Compositing was added, decorations received shadows, Qt introduced the graphics system raster and many many more changes.

Now after years the decoration temporarily woke up, but it is no longer a beauty, but ugly and old. The changing world made the decoration break. The decoration’s bits started to rot and this is visible. The truth is that the decoration will stay in the broken state as there is nobody who would want to fix it or anybody knowing the code.

What I just highlighted here is true for basically all old decorations. Of the decorations we ship only Oxygen and my theme engine Aurorae are maintained. This is a situation which can no longer continue. We have to face the truth and remove all old decorations.

But of course we don’t want to remove decorations without adequate replacement and this leads us to the story of Aurorae.

Aurorae was written to experiment with new features introduced in KWin 4.3. It was based on our common decoration API and by that is rather limited. So for 4.5 I decided to port it to the generic decoration API and reimplement with GraphicsScene instead of QWidgets. Aurorae allowed to download decorations through Get Hot New Stuff.

But given that it is a theme engine the possibilities are still very limited. Only what the theme engine supports can be rendered. Porting our old decorations to the theme engine might not be possible and not to be recommended.

But still we would like to have those decorations on a modern basis without the maintenance costs. So I started to port Aurorae to QML. This does not only give us a more powerful theme engine but also introduces QML bindings for window decorations, allowing everybody to write decorations with QtQuick.

So we can write themes without the limitations of a theme engine 🙂 This does not only remove 3000 lines of C++ code and replaces it by around 1000 lines of QML code, but also gives us an interactive decoration control module.

Interactive decoration control module

For Aurorae based themes all the buttons are interactive giving our users the possibility to really try the decoration before using it. But that’s not where it will end. I want to have new themes not based on Aurorae but using QML directly. For that I want to use the Plasma Package structure and would love to see integration in Plasmate. Another idea is to support deKorator themes inside QML.

But as always this does not come without disadvantages. Not all features which were possible with Aurorae will be available in Aurorae 3. Some features will also be dropped because hardly any theme makes use of the features, for example special backgrounds for non-composited setups. Aurorae 3 will hardly work without compositing, so it might be that we will make it a hard requirement somehow.

I hope to see many innovative QML based window decorations in 4.9.

Posted on

What’s new in KWin Scripting?

First of all a happy and successful 2012 to everyone. Let’s work together to make this year a great success for KDE!

One of the big topics in 2012 for my development efforts in KWin will be JavaScript bindings and QML. This is a technology which will allow our users to build their own custom window manager giving even greater power to our static window rules as before. It will also reduce our maintenance need when major parts of our UI can be transitioned to either QML or JavaScript.

The work on this area has already started and the first code set has been merged into master (aka 4.9). The old scripting API had manually crafted bindings for around 30 properties for windows. Now the API is generated and everything that is available for effects is also exported to JavaScript, which means more than 60 properties, more properties than before are writable and many more signals are available. Interestingly I could drop several hundreds lines of code by exporting more properties and the code becomes cleaner and better documented. These are changes I really like 🙂

The API documentation of KWin scripting is now auto-generated through Doxygen and already imported to techbase together with detailed Update Notes on what changed. If you run master and use KWin scripting be aware that you have to adjust the script. Exactly the same API will be available in QML and also the Effects API is very close – given that the property names are inspired by the Effects API.

One of my favorite changes is that our Plasma Desktop Console is now able to execute KWin Scripts:
Plasma Desktop Console executing a KWin script

To open just use KRunner and type the new keyword “wm console” or start the desktop console and switch using the toolbar button.

This is a very important change for me during development as I can easily test whether my scripts are correct and most important my implementation. But also for users it means that scripts can be tried at runtime and don’t require a KWin restart any more. So adjusting the runtime behavior becomes possible.

So what’s next? I am currently with the progress quite satisfied with the work done so far on scripting and will now concentrate on two other areas first: getting my unmerged kickoff-qml and screenlocker branch into master. Both require still a little bit of work. After that scripting and QML get my number one priority again.

Posted on

Was passierte im Fenstermanager für KDE Plasma Workspaces 4.8?

Es ist schon ziemlich lange her, dass ich hier mal auf Deutsch gebloggt habe. Nun nehme ich unser bevorstehende Release der KDE Plasma Workspaces 4.8 als Anlass um mal darüber zu berichten, was sich so im Bereich des Fenstermanagers und Compositors seit 4.7, welches in Kubuntu 11.10 zum Einsatz kommt, so getan hat.

Unser nächstes Release wird Bestandteil der LTS Version, d.h. sehr viele Kubuntu und hoffentlich auch Ubuntu Nutzer werden lange daran Freude haben.

In 4.8 sehen wir im Fenstermanager nicht besonders viele neue Funktionen. Wir haben hauptsächlich “unter der Haube” gearbeitet. An mehreren Stellen haben wir die Performance verbessert. Das Vergrößern/Verkleinern von Fenstern läuft nun dank einer verbesserten Synchronisierung mit dem Zeichnen der Fenster flüssiger. Wer es ganz flüssig haben will, sollte weiterhin den Effekt dafür verwenden.

Unser Verwischen (Blur) Effekt hat besonders viel Liebe erhalten. Alle Zwischenergebnisse werden nun im Speicher vorgehalten und nicht in jedem Frame neu berechnet. Das hat enorme Auswirkungen auf die Performance. Dank dieser Verbesserung (und einigen anderen kleinen Verbesserungen im Compositor dafür) konnte ich problemlos auf einer etwas älteren Ati X300 einen Fensterstil einsetzen, bei dem alle Fenster mit verwischtem Hintergrund gezeichnet werden. Auch können wir nun den Hintergrund von herausfahrenden Popups selbst während der Animation verwischen. Bisher hatten wir darauf verzichtet um die Performance zu schonen.

Weitere Performanceverbesserungen wurden unserem Effektsystem spendiert. Die Effekte können nun sagen ob sie gerade aktiv oder inaktiv sind. Dadurch werden sie beim Rendern eines Frames nicht berücksichtigt. Dies führt zu einer besseren Skalierung: die Anzahl geladener Effekte und offener Fenster hat keine Auswirkung mehr auf die Performance, denn in der Regel sind nur ein oder zwei Effekte gleichzeitig aktiv.

Eine sehr interessante Entwicklung ist der Einsatz von QtQuick. Diese Technologie haben wir im Fensterwechsler (Alt+Tab) eingebaut und können dadurch sehr einfach verschiedenste Layouts unterstützen. Hier ermöglichen wir unseren Nutzer eigene Layouts zu erstellen und zu verwenden. In der nächsten Version wollen wir das weiter ausbauen um auch Get Hot New Stuff zu integrieren um weitere Layouts aus dem Internet herunterladen zu können.

Generell sehen wir in QtQuick sehr viel Potential und wollen dies in 4.9 verstärkt einsetzen um den Nutzern somit ein Werkzeug in die Hand zu geben um einfacher seinen Fenstermanager zu gestalten und die eigenen Ideen in die Entwicklung einzubringen ohne C++ beherrschen zu müssen oder KDE Plasma überhaupt bauen zu müssen.

Rückblickend bin ich mit der Entwicklung in 2011 sehr zufrieden und freue mich auf das nächste Jahr um die Früchte zu ernten von der Arbeit, die wir dieses Jahr begonnen haben. Ich kann nur jedem Nutzer empfehlen den KDE Plasma Fenstermanager in Version 4.8 auszuprobieren und mal neben Unity oder GNOME Shell zu versuchen. Dank der Flexibilität unserer Desktop Shell Plasma können Nutzer auch ohne großen Aufwand ihre bevorzugte Desktop Shell – sei es Unity oder GNOME Shell – nachbauen.

Aber damit 4.8 ein richtig tolles Release wird, sind wir auf eure Mithilfe angewiesen. Aktuell ist der Release Candidate 1 veröffentlicht und wir brauchen noch mehr Tester. Von Kubuntu gibt es PPAs um die aktuelle Entwicklerversion zu bekommen. Wenn ihr ganz sicher gehen wollt, könnt ihr auch Neon verwenden, das die Pakete getrennt installiert. Testet, findet die Fehler, meldet sie, damit wir Entwickler sie noch vor dem Release beheben können.

Und wenn ihr nicht wisst, was ihr mit dem ganzen Geld machen sollt, dass ihr zu Weihnachten geschenkt bekommen habt, so empfehle ich euch eine unterstützende Mitgliedschaft im KDE e.V. (Ich bin auch zahlendes Mitglied.) Dies ist ganz wichtig, denn mit euren Spenden werden die Entwicklersprints finanziert, welche wir Entwickler benötigen um die zukünftige Entwicklung zu koordinieren. Vielen Dank!

Posted on

QML saved KWin Scripting

Over the last half year I blogged several times that I would drop KWin’s scripting component if nobody takes over the development of the code. Unfortunately up to now we have not seen any improvements. So keeping to my words I would have to drop the code.

Instead I decided to do a last try to get some work done and created some Google Code-In tasks and thanks to that the Tutorial and API documentation got imported to techbase. Example scripts are ready to be imported into kde-examples repository and we have received a KCM for managing the scripts. This is what I consider the minimal requirements for keeping scripting. Without an API documentation it’s just useless.

At the same time I have started to do my planing for the next development cycle. The main task of my work will be in the area of QML (surprise, surprise) with the aim to drop all custom GraphicsView code in KWin and replace it by QML. These are:

  • Remaining clean-up of TabBox: Desktop Switching needs to be ported, old code needs to be dropped
  • Aurorae is completely GraphicsView based and should be possible to be ported to QML. It will not just be a port of the theme engine, but will allow to write decorations in general using QML. One of the QML based decorations will then be an Aurorae theme interpreter. The long term plan for this is to get it into a state that it can replace the existing decoration API. Will need some time and some work together with Thomas and Fredrik – our decoration experts in KWin. The long term goal is to have it ready for the scene graph in Qt 5 and hopefully be able to integrate this very well with our compositor.
  • Desktop Change OSD: rather simple. Help more than welcome 🙂
  • Desktop Grid and Present Windows: our effects which use widgets. Now this is the really interesting part of my 4.9 work. Desktop Grid and Present Windows will be ported over to QML and won’t be effects in the classic sense any more. I have been dreaming for years about having effects in a state that our UX designers could do them without hacking C++. Finally we are at the state where this is possible 🙂 As a nice side effect that will make it possible to use Present Windows even without compositing – an idea Lubos told me at my first Akademy in 2008.

All those areas somehow have to access KWin Core and at the moment all have different approaches. Decorations use a “bridge” between the Client’s and their decorations and partially direct function calls.

Effects have an EffectsHandler and EffectsWindow interface representing the Core functionality and working as a proxy. So very similar to the decoration bridge but with much more functionality.

Scripting on the other hand uses a “Wrapper” to export JavaScript functions and calls then the underlying Core objects.

For QML we would have to add Properties to all the functionality which we want to have exported. Which would be the fourth technology and one to many.

Yesterday I started to add the Property definitions to our Client class and ported KWin scripting to use the properties instead of the Wrapper for Client. It breaks existing scripts, but works quite nicely so far 🙂 For me this brings scripting finally in the area where it becomes useable to me: an easy way to test my property definitions.

So we can expect that scripting will get quite some love over the next development cycle. It will be tailored towards my developer needs which will help everyone.

But not only that. Given that we now have the properties, we can also base our Effect system on them. And Thomas did some great work on a generic effect implementation. So expect a second JavaScript API to write effects 🙂

Exiting times are before us simplifying our development work and getting KWin ready for the next big step.

As I expect this to be my last blog post before Christmas I wish everybody a Merry Christmas and relaxing holidays. Thanks for using KWin and all the support I got this year for my work 🙂

Posted on

What bug statistics can tell us

Over the last months I got the feeling that lately my mail folders related to “user issues” are not getting flooded any more. Now feelings are always very subjective, so I wanted to check whether there is some truth in my feeling. Over the same time I noticed that there is much more trolling against KDE for example on the dot.

One of my mail folders is for new threads about KDE in the German ubuntuusers forum. I have received notifications for new threads for quite some time, but the mails get deleted automatically. So I asked Christopher Grebs whether he could provide me the required information. So here is a plot showing the number of new threads per month over the last few years. As it is an (k)ubuntu related forum we can expect higher number of threads in April and October.

I included the year 2007 as it was the last year with only KDE 3.5 which many users seem to praise as the best desktop environment ever without any problems. What we can see here is that the number of new threads in 2007 (average 154) is similar to the one of 2009 (average 168) while 2008 was clearly a year causing trouble to our users. Kubuntu shipped 4.1 with 08.10 and there is a huge increase in November.

But what is really impressive is the decrease in 2010 and even more in 2011. So my feeling was right, there are less new threads. In fact in 2011 (please note that there is still half a month to go) the average new threads are just 63, which is less than half of what we had in 2007.

There can of course be many reasons for that. Maybe ubuntuusers is not any more so popular, maybe users go to forum.kde.org which did not yet exist in 2007, maybe Kubuntu is no longer a popular distribution for KDE users.

But it could also show that either KDE lost many users recently or that our software became much better, much better even than KDE 3.5 has ever been.

Now I thought how can I verify that this is not related to the forum in question and for that I wanted to look at our bug database and wrote a small tool to generate some statistics (if anyone is interested in the raw data please send me a mail). So here I present the number of opened bugs per month for KWin. As opened bugs I mean bugs which are either still open or have been fixed. Duplicates, invalid bugs, etc. are ignored.

Here we have a slightly different picture. Given our release schedule we expect higher numbers at end of year and mid of year. 2007 with KDE 3.5 hardly had seen any new opened bugs till the beta of 4.0 came around. Unlike in the forum 2008 is not the year with most reported bugs. KWin did not enable compositing till 4.2 (January 2009), so it was for most early adopters just the same as the 3.5 version. We can clearly see the enabling of compositing starting at end of 2008 with the high peak after the release in February 2009 and constant high values throughout the year. But already 2010 showed less newly reported bugs and in 2011 again my feeling is correct. Currently the curve is below the one of 2007 and the average is close to 2008 again (16 compared to 17 reported bugs per month).

Now this are two datasets validating my assumption. So let’s have a look at a third one: the number of opened bugs per month for Plasma. Here it is important to know that Plasma’s bugs are not as nicely triaged as KWin bugs, so it is likely that the number of bugs is just too high.

Here we can see the same as in the KWin case: 2009 was the high bug year and 2010 and 2011 much less new bugs. In 2011 we have an average of about 82 bugs/month compared to 80 bugs/month in 2008. This is an even more impressive trend than for KWin given that Plasma is much bigger and new concepts such as Netbook shell and many more applets were added.

Now given these datasets we can clearly say that our users find less bugs in our software. The only remaining question is whether this is caused by less problems or less users. For a source-code only distribution project such as KDE it is difficult to know how many users we have and we have to notice that very often the only feedback we get is the negative one. So it is difficult to say whether there are users with no problems or no users. But also for that question we can ask bugzilla:

This graph shows us all reported bugs against KWin including duplicates. The interesting value is the “Intel Peak” in May 2011. This driver bug affected Kubuntu users with Intel GPU and enabled unredirection of fullscreen windows. So although it only affected a subset of users and DrKonqui recognized the duplicates it’s the fourth highest value for the complete data set resulting in 2011 seeing almost as many bugs reported as in 2010 (832 vs 806) with still a big chance of 2011 surpassing 2011 as in each year more bugs have been reported in December than in November. We also see the problem of the Intel bug going away with the Kubuntu release of 11.10.

Now I generated some more graphs which show us some more data. Here we have a complete graph for all bug data of KWin over the time.

Again we clearly see the Intel Peak both in the reported Bugs and Reported Crashes. In general we see very nicely the DrKonqui induced bug reports. Whenever there is a peak in the reported bugs, there is also a peak in the reported crashes.

This we can also see in Plasma. It is quite clear that very few crashes affect a large userbase. As with the case in KWin these can be upstream. E.g. I’m quite sure that the last peak in the graph has been caused by a change in Qt 4.8.

Impressive is the beginning with all bugs being more or less fixed instantly during the development. There is one more interesting thing to be seen. Twice a year Aaron starts to panic about the number of opened bugs in Plasma and I think we can see this here as well. Let’s have a closer look at the fixed bugs:

Quite an impressing work the Plasma devs are doing there. Overall I think these graphs validate that there are less bugs and it shows how our software has matured over the years.

Posted on

Experience from Porting Kickoff to QML

As mentioned last week I started to port Kickoff to QML as a training project. Now I am happy to announce that Kickoff with QML is functional and can already be used. If you want to give it a try, just checkout the kickoff-qml branch in kde-workspace and rebuild the kickoff applet. It does not overwrite the existing applet, but adds a second one called “kickoff” instead of “Application launcher”.
Kickoff QML Application View

As we can see in the screenshot Kickoff got connected to all the Models, so we can browse all the tabs, the applications and perform search.

The actual idea was to just do some QML training, but it turned out to be more a training on Qt Models. The Kickoff code is let’s call it interesting. All the tabs have an underlying Model, but what was really surpising is that all Models have a tree like structure. For the Applications Model this was to be expected, but why are the Favorites in a tree structure? As QML is still rather limited for Tree Views I changed the favorites and leave model to be a plain list model which makes it easy to use.

The systems model (applications, places and removable devices) turned out to be more challenging. It uses a QProxyModel instead of QStandardItemModels and merges the applications and places into one Model again in a tree structure. Changing this to no longer being a tree structure seemed non-trivial and I did not want to touch the C++ code. So I started to implement a Tree view in QML for the system tab. Finally I had the QML code to play around with to improve my skills.

After I succeeded in rendering a tree view I noticed a new problem: both places and removable devices showed the same entries and too many entries. It took me quite some time to figure out the problem: the Model is buggy. The proxying was not done correctly and the view so far filtered out entries not relevant to the current section – ouch. This I could not copy in QML as the row count of the Model would not match the count of shown entries resulting in wrong height calculations.

So I had to fix the Model and was back doing C++ programming. Now the Model correctly proxies the underlying Model and I can use the standard views in Kickoff as it is also no longer a tree structure. All my work on the tree view in QML was in vain *sigh*.

Last but not least I had to face the recently used Model. Like all the other Models it has a tree structure. After the experience with the Systems Model it was clear to me that I have to rewrite it as well.

After that the last remaining task was to integrate the search and finally a Model which worked exactly the way I expected it to be. Exported the Model to QML, connected the search field and there were search results. Thanks Ivan for the great job of providing a working Model without having to first fix it.

The results of the work look really promising. Kickoff is much faster, all Models are lazy loaded, that is they get only loaded if the tab is selected. So there is no delay any more when clicking the Kickoff button in the panel 🙂

Of course there is still lots of work left for me to train my QML skills. Drag’n’Drop support is missing, context menus are missing. We need some nice animations. But of course there is still lots of time till master opens up.