This week in KWin (2012, week 39)

And another week gone. Major event of course tagging of 4.9.2 and a few more bug fixes for this version. But that’s not the only work that happened. I still have a few changes under review but also merged in some further changes for the OpenGL compositor I had been working on during XDC. Nothing really special except maybe that the specific OpenGL compositors can now be referenced by an enum type which simplifies the code checking for OpenGL 1/2 specific code in the effects.


Crash Fixes

    Critical Bug Fixes

      Bug Fixes

      • 307365: Decoration broken in maximized state
        This change will be available in version 4.9.2
        Git Commit
      • 307609: Zoom effect broken in master
        This change will be available in version 4.10
        Git Commit
      • 307125: Closed Windows stay in dock apps like AWN and docky with desktop-effects enabled
        This change will be available in version 4.9.2
        Git Commit

      New Features


          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:

          kwin(17876) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
          kwin(17876) KWin::SceneOpenGL::createScene: Forcing EGL Windowing System through environment variable
          kwin(17876) KWin::EglOnXBackend::initRenderingContext: EGL version:  1 . 4
          OpenGL vendor string:                   X.Org
          OpenGL renderer string:                 Gallium 0.4 on AMD TURKS
          OpenGL version string:                  2.1 Mesa 8.0.4
          OpenGL shading language version string: 1.20
          Driver:                                 R600G
          GPU class:                              NI
          OpenGL version:                         2.1
          GLSL version:                           1.20
          Mesa version:                           8.0.4
          X server version:                       1.12.3
          Linux kernel version:                   3.2
          Direct rendering:                       yes
          Requires strict binding:                no
          GLSL shaders:                           yes
          Texture NPOT support:                   yes
          kwin(17876) KWin::ShaderManager::initShaders: Ortho Shader is valid
          kwin(17876) KWin::ShaderManager::initShaders: Generic Shader is valid
          kwin(17876) KWin::ShaderManager::initShaders: Color Shader is valid
          kwin(17876) KWin::SceneOpenGL2::SceneOpenGL2: OpenGL 2 compositing successfully initialized

          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.

          This week in KWin (2012, week 38)

          This week we have seen quite some bug fixes for 4.9.2 and the inclusion of the refactoring I blogged about in the beginning of the week. This of course still continues and more patches are in the pipeline. Also a few more effect configurations got ported over to KConfigXT.


          Crash Fixes

          • 303244: Kwin 4.9 beta crashes on logout
            This change will be available in version 4.9.2
            Git Commit
          • 305361: Kwin crashed after changing qtcurve configuration
            This change will be available in version 4.9.2
            Git Commit

          Critical Bug Fixes

            Bug Fixes

            • 289747: Desktop Grid effect gets “confused” when adding a new desktop
              This change will be available in version 4.9.2
              Git Commit
            • 301730: Ugly half drawn shadows (hardcut) in (qml)windowsswitcher grid
              This change will be available in version 4.9.2
              Git Commit
            • 306281: autoraise raises inactive window under mouse when switching workspaces or closing active window
              This change will be available in version 4.9.2
              Git Commit
            • 177495: Fullscreen windows unusable due to heavy flickering

            New Features


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

                This week I have been at the XDC 2012 kindly hosted by SUSE in Nuremberg. It was a very useful conference for me and I’m very glad I went there. There is not much difference to a KDE conference, even the N9 density was kind of the same. 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).

                Actually there is not much to write about as to a reader of my blog you are already aware of all the work I am currently putting into Wayland. It’s just that I never write that I do something with Wayland in mind, because I don’t want to hype the technology.

                Nevertheless I had been asked recently rather often about a status update and also promised that I would write a blog post if we reach the fund raising aim for the Randa sprint (thanks a lot for the great support on the last day of the fund raising campaign). 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. How that will look like, I don’t know. It’s not a problem we can tackle right now, so it does not make much sense to think a lot of it. We know we need to change a few things here and there to make it work.

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


                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.

                Given that our manpower is rather limited and given that X11 is what we have right now and we do not have the resources to develop two Compositors (one for Wayland, one for X11) it seems to me that extending KWin with Wayland support is the only possible solution right now.

                Now KWin is an X11 based window manager and compositor. It’s development started in a time when nobody expected that there could be anything else than X11, so you could say that it expects that all that exists is X11. This means the difficulty in porting KWin to Wayland is not in adding Wayland support to KWin, but in making it possible to have a KWin without X11 support or at least to be able to start KWin without needing an X Server.

                For adding the initial Wayland support to KWin which allowed to include a window in the scene graph and pass input events to it, I only needed around three days of development (that included getting used to the new windowing system and hitting my head against a wall because I was too stupid to find the documentation and too proud to ask for help).

                Current State of Porting KWin

                For me it is important that going to Wayland does not decrease the code quality of KWin. I don’t want to have many if (X11) { foo(); } else if (Wayland) { bar(); } code blocks. I want to have KWin in a state that it can be easily maintained, that we are able to maintain the X11 code base even once we all run and use Wayland.

                There is a git branch with some patches to have KWin support Wayland clients. If you look into the branch you will notice that it does not contain any new commits for more than a year. So it seems that nothing has happened in that area.

                Well that’s not true. All the work I have put into KWin over the last year have been with Wayland in mind. I have a pretty clear plan on what needs to be done inside KWin to go to Wayland and I tend to follow that plan. I get side-tracked from time to time to improve the KWin out there right now (e.g. performance improvements) but in general I follow that master plan.

                An example for that is the support for KWin Scripting. That might be surprising, what is the relationship between Scripting and Wayland? To have Scripting support I had to add Q_PROPERTIES to the class representing a window (class Toplevel) and to the class representing a managed window (class Client). This means we kind of extracted the interface of how a window needs to look like. The Client class has never be meant to be used for inheritance, so we did not know how the interface looks like. But in future we will need to have a WaylandClient and an XClient. That’s quite a change and scripting helps a lot to know how we need to make the class abstract.

                Furthermore I hope that scripting helps to allow us to perform unit testing. I do want to add a unit test for each method before turning it abstract (remember that we don’t want to break the desktop) and to ensure through testing that the X11 and Wayland based implementation behaves the same from a window management perspective.

                Another example of work going into Wayland to have the KWin improved right now is this bug I fixed some time ago. For the time being it means that when a window closes it is not raised on top of other windows any more. What has that to do with Wayland? The bug has been that KWin only kept track of the stacking order of Clients, but not of the more general class Toplevel. In order to go to Wayland and to be able to properly integrate Wayland Clients into our stacking order this had to change to keep track of the stacking order of Toplevels instead. It was a difficult to fix bug, but a very important change for going to Wayland.

                Also the refactoring work I recently blogged about is an important step on the road towards Wayland. Especially the splitting of the OpenGL compositor is very important. This means that the actual Compositor (SceneOpenGL) does no longer depend on X11. The dependency has been moved into an OpenGLBackend with currently an GlxBackend and EglOnXBackend. This makes it much easier to add further backends in future to e.g. support KWin on top of another Wayland compositor or KWin on top of KMS through libgbm.

                Personally I’m very satisfied with the progress we have made over the last year in preparing KWin for the important task of adding Wayland support. I think we are completely on schedule and the state is really looking good.

                The Schedule

                There is actually no schedule for the porting of KWin or KDE to Wayland. Many things like KDE Applications and KDE Plasma completely depend on the progress of Qt 5 and KDE Frameworks 5.

                So what about those dates one can read about in the Internets? Well that are dates coming from my presentation at last year’s Desktop Summit. I put up there a very tough time line for the case that we could get many people involved in working on Wayland. That hasn’t happened so far. Also parts of the time line were just stupid. I wanted to have a first prototype already in KWin at the time of 4.8. It just didn’t make any sense. Wayland was still a too strong moving target and distributions did not yet include the needed libraries any way, so it did not make much sense. It would not have been anything for users and in case anyone wants really to play with it or develop it, there was the branch. As that has not happened I did not see any advantage in merging the code into master.

                The second item on the time line was an idea to have Plasma Active running on Wayland rather soon, but that actually did not make any sense without Qt 5/KDE Frameworks 5. So that was really a stupid thing to put into the time line.

                The third item in the time line when we actually have everything in place had a strong “It’s done, when it’s done” and “Don’t break the desktop” note. So any references on when I said when KDE will be on Wayland is just wrong. And I do hope that I have clarified this with this blog post. The times I set out where ambitious and idiotic. I do apologize for putting them up in the first place and would kindly ask anyone to realize how idiotic they have been and no longer refer to them. Thank you.

                What next?

                I’m personally quite satisfied with the current state of preparing KWin for Wayland and I think we have reached a point where we can seriously start thinking about adding real code specific for Wayland to KWin.

                Given that we have a nicely refactored OpenGL backend I want to experiment with having KWin run on top of KMS or on top of another Wayland compositor. When I will find time for that I do not know, but given the already upcoming feature freeze it will be hard to have anything in 4.10.

                Also quite some required dependencies are not there yet. Libgbm will be out with Mesa 9.0, the release of Wayland 1.0 is expected somewhen soonish and XWayland might hit the next X-Server release which will happen around March. The dependencies are rather important as we cannot depend on unreleased code in KDE. Quite a lot people would complain if KWin would depend on an unreleased X-Server. So that is clearly something to keep in mind when adding the code. Not to mention that I run Debian Testing and don’t like building everything from code.

                An update on KDE on Wayland

                Now that I have your attention ­čÖé To get Plasma running on Wayland we first need Qt 5 and KDE Frameworks 5. An important part of going to Frameworks 5 is libplasma2. At the moment we are preparing a developer sprint in Randa to make libplasma2 happen. You can read more about the importance of this sprint in sebas’s blog post.

                KDE has started a fund raising campaign to make this sprint possible. But we are still lacking around 2000 EUR at the time of this writing and just a little bit more than 200 people participated in this fund raising.

                Now you are probably interested in getting a real update on the work which happened over the last year in the efforts to bring KDE (in particular KWin) to Wayland and I really want to provide it to you so that you don’t have to rely on articles about an informal chat over lunch. But I’m currently lacking motivation to write such a blog post. I think I would be much more motivated to write such a post if when I get home this evening from XDC I see our fund raising succeeded. It would show me that people really want to see progress in the KDE Plasma workspaces.

                Splitting up KWin’s OpenGL Compositor

                About two years ago I started with bringing KWin to the world of embedded devices by implementing OpenGL ES 2.0/EGL support. Till then the compositor supported only an OpenGL 1/GLX backend which allowed effects to use Shaders emulating the fixed functionality.

                The initial idea was to make this a compile time replacement. For OpenGL ES 2.0 one needs compile time checks anyway and so it seemed reasonable to just ifdef the main differences: GLX vs EGL. Our compositor itself already supported Shaders so this could all be done at runtime selection.

                But as those who have used OpenGL know, the difference between OpenGL 1 and OpenGL (ES) 2 is rather large. The one is using the fixed functionality and the other is using the programmable pipeline. While we had support for Shaders we actually did not yet have support for the programmable pipeline (e.g. geometries got specified in the fixed functionality way).

                The best approach would have been to just go to OpenGL 2 and the programmable pipeline directly, but back then, this seemed to be not suitable. There were (and still are) quite a lot of hardware which cannot support OpenGL 2 and the free drivers just gained support for OpenGL 2. This meant that I actually planned to have the default as it used to be on OpenGL 1 and only use the OpenGL 2 when compiled for embedded.

                Quite a challenge in the adjustments were the effects which already used Shaders. Of course I did not want to have two sets of Shaders – one for desktop and one for embedded. That would have increased the maintenance costs in a way I could not have justified. The Shaders therefore got adjusted to be for the programmable pipeline, to no longer emulate fixed functionality.

                The result of this and other adjustments were that instead of gaining one additional backend for EGL we also got a new OpenGL 2/GLX backend and it turned into the default and OpenGL 1 into the legacy backend.

                Now fast forward two years. In the meantime quite a lot has happened which I could not foresee when I started the OpenGL ES efforts. One happening is QtQuick 2 which will be used with Qt 5. KWin is already a heavy user of QtQuick 1 and of course we want to use QtQuick 2. But this will bring in a runtime dependency for OpenGL 2. So no matter whether we actually support OpenGL 1 or not, once we are using Qt 5, we will need OpenGL 2. This puts an end-of-life warning to our OpenGL 1 based legacy compositor.

                Another important development is of course Wayland which will open a complete new world of compositing to us. We will in future have to composite without an X Server. It’s still more distant future than Qt 5, but still it’s something to consider.

                And also it seems to become more clear that EGL is no longer only for embedded. It becomes possible to use OpenGL on top of EGL instead of GLX and that basically throws one of my assumptions from the porting over board. Concerning EGL we have also seen in the recent past that being able to do EGL is just one part of the game: the driver also needs to support doing EGL with X. Especially if the driver is only meant to be used for Android that is unfortunately not the case.

                Given all that I’m very unsatisfied with the design decisions I took two years ago and the way how the OpenGL scene is split into the GLX and EGL parts.

                Recently I started a refactoring session for the Compositor and did not stop there but continued into the OpenGL scene. One of the issues I wanted to tackle was to prepare KWin to be able to use EGL as a backend for OpenGL and to be able to add more EGL backends to get that problem mentioned above solved (also I recently got a Raspberry Pi and I want to see KWin running on it).

                An abstract OpenGLBackend got split out of the SceneOpenGL which is responsible for creating/releasing the OpenGL context, create Textures from window pixmaps and do the buffer swapping in the window system specific way. There are now two concrete implementations: GlxBackend and EglOnXBackend (you might guess what is the next Backend I want to implement). The advantage is now that the actual compositor does no longer need to care about the windowing system abstraction.

                OpenGL Compositor after Refactoring

                The second major refactoring in that area was to separate the OpenGL 1 and OpenGL 2 code paths. While in the past it made sense to have just one code path, this is for quite some time no longer the case. Everywhere there were checks whether we are in OpenGL 1 or 2 mode and overall it were mutual exclusive paths with some shared code. This is now nicely separated which makes the code cleaner and hopefully easier to maintain. It also means that we can move the OpenGL 2 compositor forward without doing compromises for the OpenGL 1 compositor.

                A nice addition is that first the OpenGLBackend is created (still EGL only for ES and GLX for desktop) and then the Compositor is asked whether it can use the backend. E.g. the OpenGL 2 compositor now checks whether the backend provides a direct rendering context and just refuses if this requirement is not met. This will hopefully result in some code to have better detection which driver should use OpenGL 2 and which OpenGL 1. Up to now the detection was whether the driver supports GLSL and if the Shader compilation succeeded, the GL2 compositor got used. My idea for 4.10 is to use our GLPlatform information system to tell us whether the driver should use OpenGL 2 or 1. That way we can give users of older hardware a better experience even if their hardware is – theoretically – able to do the OpenGL 2 compositing. This needs some further adjustments like an environment variable to enforce a compositor (config option already exists).

                The change also nicely grouped all the OpenGL 1 code into one area which will be easier to remove once we decide that the End of Life is reached. Removing code is not as easy as one might expect and that is actually quite a project. To go to that direction I plan to introduce a new build option to build KWin without OpenGL 1 support, which is basically the same as the build option for OpenGL ES, but the existing build option could be used for actual differences between OpenGL 2 and OpenGL ES 2.0. And of course EGL needs to be uncoupled from the OpenGL ES build option – it is totally valid to compile the EGL backend for OpenGL.

                This week in KWin (2012, week 37)

                This week I want to dedicate my summary to the following persons:

                • Salva
                • Giuseppe
                • Andrea
                • Christian
                • Dirk
                • Francesco
                • Dario
                • Alexander
                • Lilian
                • Bernhard

                I hope I haven’t forgotten anyone. They all worked on porting our effects configuration to KConfigXT and quite a number already got merged into master this week. This is truly an amazing community. I have not expected that ten people would turn up to tackle the complete project in just one week.

                The “disadvantage” is that it basically blocked my work. I was mostly involved in reviewing the patches and merging them in. It took me nevertheless about a quarter of hour to merge one of the changes as some effects are special and needed adjustments.

                Other reviews got stuck in the queue and because of that the bug list for this week just returned an empty list.

                Einf├╝hrung in Kubuntu auf der Ubucon 2012

                Auf der diesj├Ąhrigen Ubucon, welche vom 19. bis 21. Oktober in Berlin stattfindet, werde ich eine Einf├╝hrung in Kubuntu und insbesondere in die KDE Plasma Workspaces geben.

                Dies ist eine hervorragende Gelgenheit mal in Kubuntu reinzuschnuppern und das nicht nur wenn man mit den Entwicklungen bei anderen Umgebungen nicht so ganz zufrieden ist ­čśë Als Entwickler an den Workspaces kann ich bestimmt auch alten KDE Plasma Nutzern noch einige Tricks beibringen um Plasma besser zu bedienen.

                Da ich plane die Einf├╝hrung haupts├Ąchlich als Live-Vorf├╝hrung durchzuf├╝hren, kann ich anbieten, dass ich eure W├╝nsche in der Einf├╝hrung ber├╝cksichtige. Wenn es etwas gibt, was ihr angesprochen haben wollt, dann hinterlasst doch einfach einen Kommentar hier im Blog und ich werde schauen, dass ich das einbauen kann. Nat├╝rlich keine Garantie ­čÖé

                Freue mich schon viele interessierte Gesichter in Berlin zu treffen.

                Da das Programm der Ubucon anscheinend noch nicht online ist, hier mal der Abstract zu meinem Vortrag wie ich ihn im Call-For-Papers eingereicht hatte:

                Kubuntu – eine Einf├╝hrung in die KDE Plasma Workspaces

                Kubuntu ist die von der Community herausgegebene Ubuntu Variante mit Fokus auf Software der KDE Community. Anstatt dem unter Ubuntu verwendeten Unity kommt hier eine der KDE Plasma Workspaces zum Einsatz – je nach Gr├Â├če des Bildschirmes entweder eine speziell angepasste Netbook Oberfl├Ąche oder ein klassischer Desktop.

                In diesem Vortrag wird die grundlegende Verwendung von Kubuntu und der KDE Plasma Workspaces vorgestellt. KDE Plasma ist ein sehr m├Ąchtiger Desktop, der dem Nutzer unglaublich viele M├Âglichkeiten gibt, schnell, effizient und mit Freude seine Arbeit am Rechner zu vollbringen. KDE Plasma ist eine Oberfl├Ąche, die nicht Aufmerksamkeit verlangt, sondern dem Nutzer hilft seine Arbeit durchzuf├╝hren.

                Hierzu bietet Plasma interessante neue Konzepte wie Aktivit├Ąten an. Diese erlauben dem Nutzer seine Arbeit thematisch zu sortieren. Dabei wird aber diese Funktion dem Nutzer nicht aufgezwungen, sondern es ist eine n├╝tzliche Funktion, welche man benutzen kann, wenn man denn m├Âchte.

                Neben der Einf├╝hrung in die KDE Plasma Workspaces, werden auch einige der f├╝r den t├Ąglichen Gebrauch wichtigsten Anwendungen von KDE erkl├Ąrt, wie z.B. den KDE Dateimanager Dolphin oder den Bildbetrachter Gwenview, welcher auch Bilder direkt nach Facebook, Flicker und Co senden kann.

                The Importance of Developer Sprints

                Back in 2009 I was one of those lucky hackers who met in Randa, Switzerland, for a Plasma sprint. I just had started my Master Thesis, so actually I had better and more important things to do than to go to a developer sprint a few hundreds of kilometers away.

                Almost half a year later we had the next Plasma development sprint in Nuremberg. I was just finishing my Master Thesis, so again I had more important things to do. I remember that I spent as much time as possible reading and correcting my Thesis.

                Since then attending developer sprints no longer conflicted with my studies, but they conflicted with my work. To go to a developer sprint requires to take off days from work, spending your holidays to do work. This year I spent already two weeks – one for the sprint in Spain and one week for Akademy.

                Next week I will attend the XDC in Nuremberg and I’m basically out of holidays left for sprints, because I also want to go on non-work holidays this year. That’s the reason why I unfortunately cannot attend the sprint in Randa.

                Why do I write all this. Well, I want to explain that going to a sprint is nothing close to holidays. It’s actually quite some hard work and you do quite some compromises to go there. You do that, because you know how important these sprints are. Nobody benefits more from a sprint than the users. Issues which are hardly possible to discuss on a remote media like mailing lists or IRC are solved in few minutes. Developers can start hacking together on an issue to make it go away. Developers can easily see shortcomings in the software like finding anti-patterns in the software usage (yes Martin I’m looking at your systray). Last sprint I took some time to just walk around the desk with all the notebooks to study the Plasma configuration of each hacker and noticed that nobody uses a default setup. That’s quite some important finding to make Plasma better for our users, but also shows the power of configuration of Plasma.

                These are just some very few examples for the importance of a sprint. And again the most important part of it is that the users benefit from the sprint. The time will be used to make our software better. If you are a KDE user, I’m quite sure that you want to support such efforts.

                At the moment we are raising money to make this sprint possible. At the time of this writing just 144 people donated money. And that’s something that surprises me. KDE software may be free of charge, but the development is nevertheless expensive and the software has quite some worth: according to David A. Wheeler’s SLOCCount it would take 22 Person-Years to develop an application like KWin.

                Please think about whether you want to support the efforts of the KDE hackers and make this important sprint possible. It is not a sprint for us, it’s a sprint for you. We want to deliver better software to you.

                If you like me think it’s important to constantly support KDE, you could also Join the Game, KDE’s supporting member program. Although I’m donating quite some source code each year to KDE I’m also a supporting member. Oh and if you are living in Germany: KDE e.V. is a gemeinn├╝tziger Verein.

                The relevance of game rendering performance benchmarks to compositors

                In my essay about the methodology of game rendering performance benchmarks and how you should not draw any conclusions from incomplete data I did not cover a very important aspect about game rendering performance: the relevance of such benchmarks for OpenGL based compositors.

                Like my post from Saturday this post represents my personal opinion and applies to all game rendering benchmarks though the publication of one specific one triggered the writing.

                As you might guess from my way of writing and the caption, the conclusion I will provide at the end of this essay, is that such benchmarks are completely irrelevant. So I expect you to run straight to my comment section and tell me that games are extremely relevant and that the lack of games for Linux is the true reason for the death of Linux on the Desktop and Steam and Valve and Steam! Before doing so: I do know all these reasons and I considered them in this evaluation.

                The first thing to note is that OpenGL based compositing on X11 introduces a small, but noticeable overhead. This is to be expected and part of the technology in question. There is nothing surprising in that, everybody working in that area knows that. When implementing an compositor you consider the results of that and KWin’s answer to that particular problem is: “Don’t use OpenGL compositing when running games!” For this we have multiple solutions like:

                • Alt+Shift+F12
                • KWin Scripts to block compositing
                • KWin Rules to block compositing
                • Support for a Window Property to block compositing

                In the best case the game uses the provided property to just say “I need all resources, turn off your stupid compositing”. It looks like we will soon have a standardized way for that, thanks to the work done by GNOME developers.

                Of course we could also optimize our rendering stack to be better for games. In the brainstorm section the question was already raised why unredirection of fullscreen windows is not enabled by default given the results published in the known benchmark (one of the reasons why I don’t like these benchmarks, so far every time we got bug reports or feature requests based on the incorrect interpretation of the provided data).

                Optimizing the defaults means to adjust the settings for the needs of a specific group of users. Unredirection of fullscreen windows has disadvantages (e.g. flickering, crashes with distribution/driver combinations when unlocking the screen) and one has to consider that carefully. Gaming is just one of many possible tasks you can do with a computer. I hardly do games, I use my computer for browsing the Internet, writing lengthy blog posts, hanging out in social networks, sometimes watching TV or a video on youtube and hacking code. All these activities would not benefit from optimizing for games, the introduced flickering would clearly harm my watching TV activity. So if you think games are important, please step back and think how many activities you do and how much of it is gaming.

                The next point I want to consider in the discussion is the hardware, especially the screen. As such benchmarks are published to be applied for general consumption we can assume standard hardware and a standard screen renders at 60 Hz. This is an extremely important value to be remembered during the discussion.

                Now I know that many people think it’s important to render as many frames as possible, but that is not the case. If you do not reach 60 frames per seconds, it’s true – the more the better. If you reach 61 frames per seconds, you render one frame which will never end up on the screen. It’s not about that it’s more frames than your eye could see, it’s about the screen not being able to render more than 60 frames per seconds physically. Rendering more than 60 frames per second is a waste of your resources, of your CPU, of your GPU of energy, of your money.

                Given that we can divide the benchmark results in two categories: those which are below 60 fps and those which are above 60 fps.

                A compositor should not have any problems rendering at 60 frames per seconds. That’s what it’s written for and there is nothing easier than rendering a full-screen game. It’s the most simple task. Rendering from top-to-bottom all opaque windows, stopping after rendering the first one (the game) because nothing would end on the screen anyway. Perfect. It’s really the most simple task (considering it uses a sane RGB visual). If a compositor is not able to render that at 60 frames per seconds, something is fundamentally broken.

                Let’s start with looking at the first category. I already pointed out on Saturday the one run benchmark where the result has been 10 frames per seconds. This is a result we can discard. It’s not representing the real world. Nobody is going to play a game at 10 frames per seconds. That just hurts your eyes, you won’t do it. The overhead introduces by the compositor does not matter when being in the category “too slow”. We can consider anything underneath 60 frames per seconds as “the hardware is not capable of running that game”, the user should change the settings or upgrade. This will turn the game into having more than 60 frames per seconds.

                Before I want to discuss the second category I want to point out another hardware limitation: the GPU. This is a shared resource between the compositor and the game. Both want to use the rendering capabilities provided by the GPU, both want to upload their textures into the RAM of the GPU. Another shared resource is the CPU, but given modern multi-core architectures that luckily hardly matters.

                Looking at the data provided we see at least one example where the game renders with more than 120 frames per seconds. That is twice the amount of frames than the hardware is capable to render. The reason for this is probably that the game is run in a kind of benchmark mode to render as many frames as possible. Now that is a nice lab situation but not a real world situation. In real world the game would hopefully cap at 60 frames per second, if not at least I would consider it as a bug.

                But what’s the result of trying to provide as many frames as possible. Well it produces overhead. In that case the compositor get’s approximately twice as many damage events from the game than there need to be. Instead of signaling once a frame it’s twice. That means the event needs to be processed twice. It doubles the complete computational overhead to schedule a new frame. It does not only keep the compositor busy, but also the X-Server. So part of the shared resource (CPU) is used in a completely useless way. This of course includes additional context switches and additional CPU usage which would otherwise be available to the game.

                Of course given that the game runs at “give me everything which is possible”, the available resources for the compositor are lower. This can of course result in frame drop in the compositor and also in badly influencing the run game.

                But it is not a real world situation. The problem that the compositor does not get enough resources or takes away the resources from the game is introduced by the game running at a too high frame rate. So to say it is an academic example. Such benchmarks matter to game developers like Valve who really need to know how fast the game can go, but I’m quite confident that they also know about the side-effects of having a compositor (and other applications) and run it on a blank X-Server which I suggested as the control in my post from Saturday.

                Given that I can only conclude that such benchmarks show data which are not relevant to the real world. It’s a lab setup and as so often a lab setup doesn’t fit to reality.

                And this shows another problem of the benchmark. It shows nice numbers, but it does not answer the only valid question: is the game playable. In the end does it matter to the user whether a game renders at two frames more or less depending on which compositor is used as long as it doesn’t affect the game play? I would say it doesn’t matter.

                It would be possible to setup a benchmark which could highlight regressions in a compositor. But the result would in most cases several bars all at 60 fps and if not, it’s a reason to report a bug and not to do a news posting about it. As an example for a benchmark done right, I want to point to the benchmark provided by Owen Taylor from GNOME Shell fame. Nowadays I know that the data provided in this benchmark nicely shows the performance problem which we fixed in 4.8. Back when the benchmark was published I thought it’s an issue with the benchmark and tried it with all available rendering backends of KWin and always got the same problem (and also studied the code). So yes proper done benchmarks, considering real world situations can be helpful, but even then it needs someone with expertise from the field to interpret the provided data. That’s also an important aspect missing in most benchmarks. A “here we see that KWin is two frames faster than Compiz”, is no interpretations.