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.

24. September 2012

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.

Summary

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

Tasks

21. September 2012

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

KWin

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

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.

18. September 2012

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.

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.

16. September 2012

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.

9. September 2012

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.

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