Posted on

KWin and Plasma Active

Plasma Active is an extremely awesome project and I am really looking forward to work on it and have my first own Plasma powered tablet. Of course KWin will be the Compositor and Window Manager in Plasma Active. And this is pretty awesome and very interesting for our future development.

KWin on OpenGL ES 2.0

Plasma Active will probably be the first large installation to make use of our new OpenGL ES 2.0 based compositing backend. In fact OpenGL ES is our primary target because the API is way more advanced than desktop GL and gives better results. Unfortunately the decision whether to use desktop GL or OpenGL ES is a compile time decision. As not all drivers support OpenGL ES on the desktop we still need to default to desktop GL. On Plasma Active we know the driver to be used and therefore can compile against OpenGL ES if supported.

OpenGL ES is far less complex than desktop GL. The desktop stack still carries around the complete outdated and deprecated OpenGL 1.x functionality. It is not surprising that writing a desktop GL driver is difficult. Because of that I expect that the hardware running KWin in Plasma Active will be faster, more energy efficient and magnitudes more stable. It will be the first important step to leave the messy state of OpenGL on Linux behind us.

Different Focus

While Plasma Active still requires a window manager, the superb functionality known from our desktop and netbook shells are not required. By targeting touch screens without keyboards quite some changes to our way of thinking how to manage windows are required. My personal pet Alt+Tab is completely useless on such a device. In order to make it usable we will need to adjust and drop the requirement of holding the "Alt" key. This will of course benefit the desktop users: switching windows could become possible with multi-touch gestures on a touchpad.

Another area of change will occur for window decorations. In fact in Plasma Active there won’t be window decorations – they are just not needed. No, I don’t twist my mind, we won’t introduce client side decorations. We just won’t have decorations. The only relevant button (close) is put into the panel. Also that will need some small tweaking of the KWin source code like many other little advantages we have to make which all will also benefit the desktop.

KWin and the Device Spectrum

Plasma supports the complete Device Spectrum by using custom shells and different QML files for the widgets. Now KWin does not (yet) support the various form factors in such a way. From the window management perspective there is nothing to change. Since the introduction of the netbook shell we know that adjusting KWin just means to change the configuration. KWin already includes all the little tweaks required to have a pleasant experience on systems different to the desktop.

Also in the compositor there is hardly anything to do. We support OpenGL ES and the general compositing doesn’t change just because we run on a gadget. There might be some adjustments required for the drivers as we did not yet have the chance to play with many of them but in general I expect everything to "just work".

The only field which requires adjustments are the effects. Many effects are just not suited for such devices and we will not ship them. In fact I expect that we won’t even allow to customize the window manager and effect system. The danger to harm the system are too high. And some of our effects need adjustments for the use on such a device. Let’s take the Present Windows effect as an example. It allows to close a window when hovering over it. Closing windows from the overview is damn useful (I got the inspiration from Maemo), but hovering is just not possible on a touch device.

In order to properly support both Present Windows on the desktop as well as Present Windows in Plasma Active we need two distinct Present Windows effects. Now writing something like Present Windows is far from trivial. The effect is complex and around 2000 lines of code. We need a better solution for that.

Over the last weeks and months even before I knew about Plasma Active I started to think about how I want to have effects being developed. My aim is that Nuno is not only able to write effects, but that he wants to write the effects. My task is to give him the tools to do so. Over Tokamak next week I will sit down with our QML and JavaScript binding experts to discuss and implement a solution for KWin. A subset of the kwineffects API will be stabilized and be made available for bindings. After lots of thinking I am sure to have found a solution which allows us to write effects in JavaScript and/or QML without spending time in the interpreted part during screen rendering. This will allow us to write effects in a more suited language with the speed of compiled C++ code. The first effect I want to port to the new system will be the Present Windows effect.

In that regard I want to have Plasmate also as a development tool for KWin effects. This will take some time, but I have ideas how we can get previews for the animations and effects outside of KWin. I am both looking forward to implement these parts as well seeing them used.

New Technology for the Desktop

Some of my last blog posts were rather controversial and that was not by chance. I wanted to test out how users will accept the changes which are implied by Wayland. I wanted to see how much acceptance there is for removing features on the Desktop in order to go to a new windowing system. I am very thankful for all the comments I received and that there was some media coverage about these posts. It was very enlightening to read all those articles and comments to them.

My fear that it is not yet acceptable to aim for Wayland was overall confirmed. Especially for KDE it seems that our users do not want us to remove any features. Everything has to be configurable, we "may not go down the GNOME road". For the adoption of Wayland we have a chicken and egg problem: as long as it is not used, applications won’t be ported, as long as applications are not ported it won’t be used. This is similar to what KDE faced in late 2007.

Now Plasma Active gives us new possibilities. Having compositing always enabled is not just a nice thing, it is a requirement which we can fulfill thanks to the advanced drivers compared to the broken state on desktop. We can experiment with moving the screensaver into the compositor without ensuring backwards compatibility. We even do not need to support widgets in screen locker on Plasma Active. This gives us the advantage of first implementing the new functionality and later add the backward compatibility layer for the desktop systems.

And now: Wayland. Wayland is a very interesting technology but it will be difficult to embrace. There is so much depending on X that we have to either port everything and then do the big switch or dare to break functionality. Both is hardly possible on the desktop. Announcements like Mark Shuttleworth’s "Ubuntu 11.10 might use Wayland" do not cause joy in me but fear that it will harm the platform like the too early switch to PulseAudio. Wayland is too important to risk that users think it’s bad because someone just wants to be quick.

Plasma Active on the other hand is a wonderful candidate to embrace Wayland. The stack would significantly benefit from dropping X11 and using Wayland as the windowing system. The driver situation is good: the devices run OpenGL ES 2.0 which is a requirement for Wayland. But most important: we don’t need the window manager. We only need the compositor and effect system – both is basically independent of the X11 stack and can rather easily be made Wayland ready. On Plasma Active we don’t have window decorations, so we don’t need to port them and so on and so on. This gives us a third possible strategy for approaching Wayland: port step by step and use it and do not switch on the desktop before everything is put together. Please don’t over estimate this statement: it is a long road to Wayland and the first release of Plasma Active will not use Wayland. There is lots of work to be done in KWin before we will consider to add support for Wayland. This will most likely not happen in 2011.

How to get involved

KWin can use helping hands. We are only three developers and none of us can work fulltime on KWin. There is enough work to be done for fulltime developers, so we need new blood. Especially after the first support for JavaScript and/or QML is added we need help to get effects written in that language and Plasmate adjusted. These are things I would not want to do. So please get in touch with us either through the mailing list or in one of our IRC channels: #kwin, #plasma or #active are all fine. Please don’t overrun us, we are a small group 😉

=-=-=-=-=
Powered by Blogilo

Posted on

Why Blur Does Not Work in Kubuntu Natty With Intel

Over the last week we received quite some complaints about blur not working after an upgrade to the latest beta of Kubuntu Natty. So far we could not make anything out of it. All users had already been using Plasma Workspaces 4.6.2 in Maverick and were often using the Xorg Edgers drivers. So you would assume that they had more or less the same software versions like before the upgrade.

Furthermore we had not changed anything. We haven’t touched blur effect for some time – a git log does only show changes relevant to our development version. So a very strange happening. Now finally we received a bug report enlightening us. Apparently the Intel driver changed the renderer string in a minor driver release, causing our direct rendering check to disable direct rendering and by that blur cannot be enabled any more.

Here on my notebook running openSUSE 11.4 the renderer string looks like the following: "Mesa DRI Intel(R) Ironlake Mobile GEM 20100330 DEVELOPMENT" Our code to test whether direct rendering is supported looks like this:

// Assume that direct rendering works with DRI2 drivers

const GLubyte *renderer = glGetString(GL_RENDERER);

if (strstr((const char *)renderer, "DRI2"))

return 0;

// The Intel driver doesn’t have DRI2 in the renderer string

if (strstr((const char *)renderer, "GEM"))

return 0;

The code has last been changed on June 13th 2010! The section for Intel driver has been included end of May of last year. So the code is around for nearly a year. Now according to the bug report the Intel driver dropped the "GEM" from the renderer string. With the result that direct rendering does not get enabled anymore.

This change has happened in a minor release of Mesa. And I’m asking: Why? Why change what is not broken? Why introduce such a change in a minor version? Why oh why? I would accept it for a major version. We would have known beforehand and could have adjusted for our next major version. But we cannot change something like that in a minor version. And it would not help the situation. Natty will ship 4.6.2 and our next bug fix release will be after the release of Natty and I won’t accept a patch to that code as I fear that it could break for other Intel users.

I must say that I am very disappointed by this change and very, very sad. After all the trouble of the 4.5 release caused by the broken state of graphics drivers on Linux the driver developers again broke one of their most important downstreams. Maybe the message has not yet come through: nobody will use your drivers on Linux to run fancy games if the basic compositors do not work. So it is completely unacceptable to break Mutter, Compiz or KWin. Those three applications are your most important targets and whatever you do: DON’T BREAK THEM!

The sad state is that the driver developers do not even do the most simple regression test after such a change like starting into Plasma Workspaces and see if everything is working fine. It is also disappointing to see that they do not know what parts of their driver string is parsed by their most important clients. I’m now doing this kind of stuff for more than three years and changing the driver strings seems to be a hobby of the free drivers. The only driver which has in that time not change the pattern is NVIDIA. Apparently they recognize that customers may parse this information and rely on it. But of course as we all are open source evangelists it would be completely unacceptable to recommend the use of the NVIDIA driver or to recommend people to buy NVIDIA cards because their driver is bad, bad, bad just by the fact that it is closed!

Now we all remember the time of the 4.5 release and how the drivers announced support for what they don’t support. At that time the driver developers justified themselves with we should have known better, asked or at least assume that if the drivers say they support version X, that they in fact only support version X-2. Now my question: how should we handle such custom adjustments for broken drivers if the drivers change how they can be recognized?

The last time people complained that we did not communicate with the driver developers, but that I wrote an angry blog post just like this one. So I need to explain: Nobody informed us that the driver string will change. Now I am kind of stupid, I know. Even in my worst nightmares I would not expect that the developers change the version string in minor revision. Still I could talk to them now instead of writing angry blog posts? Sadly I cannot. First of all we were notified about the change too late to do anything. As just explained we were notified after 4.6.2 and no chance to adjust before Natty. Furthermore I was ill last week, are sitting in a plane to the US right now, so I can write blog posts but cannot use Internet and I will stay more or less disconnected throughout the next week.

Luckily KWin is prepared for driver fuckups and there are workarounds to this problem. An affected user can start KWin with "KWIN_DIRECT_GL=1 kwin –replace &" to enforce direct rendering and skip the checks.

A few weeks ago I suggested on our mailing lists to enforce compositing. Overall the response from my fellow developers was that they expected further driver fuckups in the future causing a hard time for our users. I disagreed and pointed out the improved driver situation and that after the 4.5 fiasco the message has got through. How could I have been so naive? It looks like we will never be able to have a decent composited sAetup with this mess of a stack 🙁

=-=-=-=-=
Powered by Blogilo

Posted on

KWin and Plasma Won’t Merge – Not Even in “KDE 5”

Today reading through planetkde gave me quite a WTF moment. The merge of KWin and Plasma was announced for KDE 5. This is quite a WTF if I do not know about that. In fact I do not even know of anything “KDE 5”. So be assured: there are no plans to merge KWin and Plasma – not even in a hypothetical KDE 5. This does not make sense, would bring no benefits and the “advantages” posted in the blog post cannot be achieved by merging the code bases.

It would be nice if bloggers would at least ask one of the maintainers of the software in question if they have any plans in that direction before posting it on planetkde which is picked up by media. We have enough work to do without correcting non-sense or discussing how best to break the desktop.

=-=-=-=-=
Powered by Blogilo

Posted on

Rethinking Screensavers

Screensavers are a relict of the last century. They were required to prevent serious hardware damage on CRT screens. This is even implied by the name: a screensaver saves the screen from damage. Now we live in the second decade of the 21st century and the world has changed. I can’t remember when I last saw a CRT computer screen, they have been completely replaced by LCD screens. LCD screens on the other hand don’t show the danger of burn-ins. They don’t need to be “saved”. Nevertheless we still have screensavers.

Nowadays screen savers are used to indicate that the screen has been locked. It is a way to animate the screenlocker. But is that wise at all? Especially in the current time it is extremly important to save power. This means if a screen is locked the screen should turn itself off, the CPU should go into the lowest power state, the compositor should stop repainting the screen, the GPU should go into the lowest power state and so on and so on. But is that possible if a screen saver is active?
The screensaver implementation in the X11 world is rather dated: XScreenSavers were first published in 1992. To be honest: most screensavers even look like being from the last century. Now if a screensaver is active, the CPU has to calculate the animation which implies that it cannot be in idle state. The compositor needs to update the screen which means the compositing engine cannot turn itself off. This implies again that the GPU cannot turn itself in the sleep mode and can cause really heavy load if the compositor needs to constantly do full repaints. Last but not least if the system DPMS is misconfigured the screen will not turn off.
In summary a system will waste power in a situation where it does not need to use any power. It is even possible that (depending on the used screensaver) the system needs more power in the idle state than under usage. Given the world we live in, I want to do something about it. We need to stop wasting power.
The waste of power is not the only disadvantage of the current screen locker system. Several of the existing screensavers have issues as they pre-date the current infrastructure with compositors by years. We have seen that parts of the screen can be leaked which means there can be privacy issues. Even worse is the situation with OpenGL screensavers. They sometimes use ARGB windows and don’t clear the screen (this used to work fine in the pre-compositing era), all areas not repainted by the screensaver are leaked. In case you have a buggy driver it is even likely that either the screensaver or the compositor will not survive that both are used. According to our bug reports this is a common problem. Now driver bugs should be fixed but reality shows: it is not happening.
For the future there is only one obvious solution: the screen locker has to be moved into the compositor. The compositor can ensure that the screen is blanked correctly and not leaking information. If the locker is part of the compositor, it can ensure that the compositing re-paint loop is stopped as long as nothing has to be shown. Only if the unlock dialog is shown the compositor needs to enable repainting and can ensure that everything else except the dialog is blanked. Another small advantage of having the screen locker in the compositor is that we can finally do a nice fade in/out when locking/unlocking the screen.
Removing the screen saver is nothing which will happen for 4.7 as it requires coordinated development. Even if we move screen locking into the compositor we need to ensure that the old architecture is still in place in case KWin is not used or compositing turned off. There is also the Plasmoids on screen locker implementation which is a valid use case and needs to be ported to any new infrastructure. This can become tricky, but I am positive that we will be able to support it. Altogether this is something I want to have for 4.8 and it is something I want to discuss at Tokamak and will make sense to be included in Plasma Active as we there have the control over the compositor which is used and saving as much power as possible is very important for the targeted devices.

=-=-=-=-=
Powered by Blogilo

Posted on

Welcoming a new OpenGL Compositor

With the release of GNOME 3 the third major Window Manager (Metacity) entered the field of OpenGL based compositing in the incarnation of Mutter. Congratulations! Now I know some will say that Mutter was around before, but with GNOME 3 it’s the first release for a non-niche product like Moblin and Unity (10.10) and is targeting desktop computers as well. I hope to find the time to play around with GNOME Shell a little bit. I wanted to try some weeks ago but even on my Intel system I only got the fallback mode 🙁

Personally I am very interested in some of the aspects of Mutter and I am eager to see how Mutter will perform under the new conditions it will be put through by the users. While KWin and Compiz are very similar using C++ and OpenGL directly, Mutter is very different. As the name implies it uses Clutter as a scene graph. So instead of directly transforming the scene with OpenGL, Mutter uses an abstraction library wich does not directly map the OpenGL semantics.
Internally KWin also has it’s own scene graph, which allows us to write Effects without any knowledge of OpenGL. So for example Present Windows uses only the built-in functionality to translate and scale windows and the same code base works with all our compositing backends: XRender, OpenGL 1.x, OpenGL 2.x/OpenGL ES 2.0. The rendering itself is done using our own custom OpenGL code. Compiz is from the architecture very similar which allows us to share ideas and sometimes even code (Compiz and KWin are much closer as you might think, for example we have the same perspective projection matrix). Sharing more than ideas with Mutter/GNOME Shell seems to be impossible, unfortunatelly.
Given my own experience I know that introducing a new OpenGL compositor can be difficult. It takes time till you know all the required quirks for all the various hardware and drivers and it takes many bug reports to learn about them. Here I am very interested to see how Mutter will perform as the compositing is based on an existing OpenGL abstraction layer. Will they hit the same problems as we did and if yes how will they be able to deal with them given that they cannot change the rendering code directly? KWin has learned a lot about drivers during the last year and nowadays we can go down to disable specific features based on hardware chips, drivers and versions. This allows us to tackle severe issues even in minor revisions.
Another point I’m interested in is the usage of a scene graph library in general. KWin’s internal scene graph is tamed to the needs of an OpenGL compositor. On the other hand Clutter is a general purpose scene graph not only developed for compositors. Of course you would expect that Clutter’s OpenGL is better given that the developers are only working on OpenGL and do not need to maintain a window manager. But a compositor is very different to all other applications. For us the most important part is the texture from pixmap operation, which is hardly needed by non-compositors. But advanced OpenGL functionality is hardly required in an compositor: KWin for example does not use a z-buffer or stencil buffers.
As indicated in my last blog post I would like to be able to always enable compositing for all users. Here I want to thank all people who commented on the post – this is highly appreciated and the feedback will be evaluated. Now Mutter or in fact GNOME Shell is a step ahead: they require compositing. But as I also outlined in my last post there are situations where you don’t want to have compositing – and I know what I’m talking about: my primary system does not wake up from suspend if compositing is enabled. I am really interested in seeing how Mutter handles such situations where you actually don’t want compositing and I hope to learn from them in these aspects. I am really looking forward to talk about such issues at Desktop Summit with the Mutter developers.
The last important point I will study with the advance of Mutter (and also Unity) is the tight integration of Compositor and Desktop Shell. In the KDE Plasma Workspaces Compositor and Desktop Shell are two separate processes which allows to use KWin with any Desktop Shell (excluding GNOME Shell and Unity) and Plasma with any Window Manager (with or without compositing support). Given the new development of missing interoperability between desktop shells, keeping the option to use a different window manager becomes less important. In fact with Wayland it might even be stupid to not have the desktop shell (and many other parts) in the compositor and switching compositors might be impossible at all. I really want to know about the advantages of having Desktop Shell and Compositor in one process and one rendering graph. There are many aspects in Plasma which can be done better in the compositor and we already make use of it – like the sliding popus, but there is much more. This is btw. a wonderful way to get involved with KDE development 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

Turning Compositing off in the Right Way

I have a dream: a dream of an always composited desktop. There are use cases for using compositing and there are usecases for not using compositing. For the user it is very difficult to know what he currently needs and can do a very bad job at deciding himself. A good example for that is turning compositing off to save some more minutes of battery. I personally doubt that turning compositing off will save battery, but will cause a further drain. How is that possible, you might ask? When compositing is turned off, Plasma starts to change the backgrounds of all SVGs causing in the worst case a re-rendering of all of them. This is costly and will most likely drain more battery than using compositing. 

Another example are fullscreen applications. Currently KWin supports unredirecting of fullscreen windows. This means the screen is no longer composited, but the resources, that is the OpenGL context and the effect system is still running. For applications like a web browser or an office suite it is completely useless, while for OpenGL applications like games just unredirction might not be enough. If you have one of those awesome drivers not supporting two OpenGL contexts at the same time, you might see either artefacts or a crashing KWin. For games there is only one proper solution: turn off compositing. The same is true for watching Full-HD videos: often graphics cards are not powerfull enough to do both compositing and GPU accelerated decoding.
Now KWin supports the solution for this: suspending of compositing. Just press Alt+Shift+F12 (or for the more technical users: use a script to change the state through DBus) to suspend compositing. The OpenGL context is removed, the effect system turned down and you have the plain old X desktop. Of course we cannot demand from our users that they know about it and can handle it. Therefore we need a bettter system.
This is what Thomas has been working on lately. First of all he removed the difference between disabled effects and suspended effects. If you disable effects it will just suspend them and the effect system will be in suspended state after a restart. This should make everything more clear to the user. The second part Thomas has been working on is allowing applications to block compositing. This is pretty awesome. Let’s say we want to watch a video in VLC. As soon as you would switch to fullscreen, VLC would set an X property to tell KWin “now please don’t composite”. KWin will suspend compositing and keep the state untill no window blocks compositing. So the GPU is completely free for VLC. Now what is the difference to the unredirection, you may ask? Imagine a user notification would pop up. With unredirection compositing would be started again, causing an ugly flickering and taking away important resources from VLC. With the new solution a notification would not cause a restart of compositing. Everything is still with VLC. On the other hand a web browser would not block compositing as that is not what the user wants. Here we need the complete advantage of a composited system as it’s not a single task such as watching a video or playing a 3D shooter. I really hope that video players, games and Wine pick up our new property and we will also recommend it as an additon to the NETWM specification.
Though the last piece might turn out difficult. While Plasma completely supports being without compositing, the world looks different with the two new Desktop Shells to be released this month. In my humble opinion both are fundamentally flawed concerning the fallback to no compositing. My biggest concern towards GNOME Shell has been from the beginning that it requires OpenGL (I talked about that part with Owen Taylor at GCDS). There is no fallback except GNOME Panel. Which at least looks for me unacceptable to switch the desktop shell just because you want to watch a Full-HD video. Now Canonical did the same fundamental mistake with Unity. It also requires an OpenGL compositor (in that case Compiz). While Compiz nowadays supports non-OpenGL I do not know how good this is and whether Unity supports it. Currently the fallback is also GNOME Panel, in future maybe Unity2D? Plasma on the other hand just needs to switch the rendering of SVGs (which is part of the style) and will lose some functionality, such as thumbnails in taskbar tooltips, Present Windows effect or Desktop Grid. The basic working with the system remains the same. Another big thumbs up for getting the right abstraction layers.
Now with Thomas work I am confident that we will be able to remove the UI to turn on/off compositing in maybe 4.8. It will just not be needed any more. The applications will take care of providing the right user experience to the users. When compositing is needed, it is on, when compositing is bad at the moment, it is off. The users won’t have to care about the state anymore and an ugly hack like unredirection of fullscreen windows can be removed. I am looking forward to such improved ways of desktop compositing 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

Menu Button inside Window Decorations

Peter Penz blogged about removing the Menu from Dolphin. While this is very interesting and nice looking I have a better idea: why not move the menu into the decoration? All what we need is already there. We have the awesome DBus Menu which allows us to send the menu to any other application (in most cases Plasma). So we could use this technology to direct the menu from the window into its decoration. Of course the menu should not be presented in its full completeness but be compacted into one dropdown menu – just like in the Netbook Shell.

So before you all start removing the Menu bar from your apps lets tackle it in a better way. If anyone is interested in working on it, please contact me 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

KWin at GSoC 2011

At this years Google Summer of Code it is of course also possible to work on KWin. At the KDE ideas page we have three projects listed, but it’s also possible to come up with an own idea. I will shortly outline the three projects:

  1. Refactoring of KWin core: KWin core has grown over the last decade and the development had a shift from being a pure X11 window manager to an OpenGL compositor with X11 window manager and soon to be only a Wayland compositor. In order to get to this new field we need to refactor great parts of the Window Manager to reuse the code in the future. As a matter of fact for this project a very close communication with me and the other developers is required. This is clearly the most important GSoC project we propose and I will be very selective on the student to choose. Developing skills are not the most important factor here, but soft skills will highly influence my decision.
  2. Unit Testing Framework for the X11 Window Manager: Since 4.6 KWin includes a scripting component which now allows us to execute small pieces of JavaScript. This component should be extended into a framework to run automated tests against the window manager. As it is clear this project is especially important for the refactoring task to ensure that any code changes do not break existing code. The student who wants to work on this task needs to be in constant contact with the student working on the refactoring to know what tests are required, soon.
  3. Initial support for Wayland clients: This is a research project and code written in this GSoC would most likely not be merged into master. The idea is to add Wayland clients to the compositor, so that they can be rendered just as a normal X11 window. As Wayland is still a highly moving target including the code directly into master does not make sense yet. The project would help to understand what needs to be done to support Wayland in KWin and would help to outline the porting. To make it clear: a complete port of KWin to Wayland is not possible in the scope of a GSoC.
Additional to the KWin mentored projects, there is also a proposed project by OpenICC to provide colour management in KWin. This project will also require collaboration with the KWin developers as the functionality needs to be either implemented as an effect or in the compositor directly.
Further KWin related topics are in the area of Plasma. There are quite some features implemented in Plasma which should be moved into the Compositor for better performance or parts of KWin which need to be made available to Plasma. Possible areas are joined screen edge handling, a merged context menu for window decoration and tasks manager, better Tooltip transitions by using an effect or synchronising window tabs and task groups. Many more areas exist. If you are interested feel free to contact KWin and Plasma developers.
I hope to see many good proposals and are looking forward to work with you to make KWin rock even more!

=-=-=-=-=
Powered by Blogilo

Posted on

New KWin Shadows

One of the features which got killed in the process of porting KWin’s Compositor to OpenGL ES was the Shadow effect. For some time already the Shadow effect was not on the level we expect from our components. The code had become too complex to maintain and the port to OpenGL ES would not have been trivial. So the port was a good point to step back and think about what we actually need in the Shadow effect.

For quite some time we have an improved shadow system which allows the window decoration to provide the Shadow for decorated windows. This is used by e.g. Oxygen, QtCurve and Aurorae. So most windows already have a very advanced and good looking shadow. The Shadow effect itself is only used for so-called unmanaged windows such as menus or drop-down lists and for “legacy” window decorations such as Plastik.
The obvious disadvantage is that menus have a different shadow than all other windows. This means the designers do not have control over the shadows. But shadows are an important part of the design. A shadow should follow the widget style’s light model and by that one shadow to rule them all is just not possible.
Since I started to consider dropping the Shadow effect I have been in contact with mostly Hugo from Oxygen fame to gather the requirements for a new Shadow system. After long and fruitful discussions also including members from other Widget Styles and Compiz we designed a new system. Hugo recently implemented the Oxygen part and this weekend I implemented the first OpenGL version of the new system:
The main difference to the old system is that the Shadow is no longer an effect but moved directly into the Compositor. This follows the approach of the Decoration Shadows which are also directly in the Compositor. By moving the Shadow into the Compositor we can better control and optimize the rendering process. The compositor itself knows about the existence of the Shadow and can update the correct screen areas. As the shadow is rendered together with window it follows automatically opacity or transformations like wobbling.
A nice addition of the new Shadow system is that it is completely controlled by the to be rendered window which allows to use it also for Plasma elements such as the Panel shadow or in KRunner (yeah no more clickable Shadow). What could also be very nice is to use it for shaped windows. Up to now windows with custom shape could not get a Shadow as our effect just could not know if it looks good in the end. The window itself knows its shape and can provide a shadow adjusted for the window. So maybe Yakuake will soon have a Shadow 🙂
If someone wants to test it, you can build the kwin/oxygen-shadows branches in kdelibs and kde-workspace. There is still some work to be done like the XRender implementation, some optimizations and currently “normal” windows are not yet supported. Also we would like to have some fallback for windows not useing either Oxygen decoration or widget style.
I hope that we can bring our system as an addition to the EWMH specification. The system has been designed to not be KWin or KDE specific and it’s a usecase actually required in all Desktop Shells.

=-=-=-=-=
Powered by Blogilo

Posted on

Comparing Commit Histories

This weekend I was looking a little bit at the bug statistics provided by Bugzilla. I was a slightly surprised by the fact that before 4.0 the numbers of open and fixed bugs hardly changed and started to skyrocket around the 4.0 release. During the last three years almost as many bugs have been fixed as in the eight years before. The number of duplicate reports even trippled, nevertheless the number of open bugs is constantly increasing. I will address the implications of this “bug problem” in a separate blog post.

As I joined the KWin development team around the 4.0 release I was interested in seeing how the commit rate around the time was. Did the development speed change, has there been a more severe impact to the codebase than at different times? Thanks to git I have the complete history around, so I did a useful formatting, wrote a small program to get the data I’m interested in and created diagrams using LibreOffice Calc[1].
Commits and Developers in KWin per year
As we can see around before 2008 KWin development clearly did not stagnate. Since 2006 the number of commits per year and developers who did at least one commit per year got a significant boost. This might be related to the porting to KDE 4 and the work on the compositor, but even after 2008 the commit rate was more or less the same. Till 2006 the avarage yearly commit rate was 360 commits, from 2007 till 2010 around 890 commits per year. Please don’t misinterpret the last data paint as a reduced activity. In fact the opposite is the case. At the end of 2010 I worked outside our SVN repository and the commits hit git in 2011 which explains that we already have half of the commits of 2010 in the (not yet) three month of 2011.
This brings me to the next point. How much does KWin depend on the development of a small group of developers? We can see that in average about 45 inidividual people committed to the KWin source code per year. Altogether 275 individual developers contributed to KWin and 10 developers have committed more than 100 changes, and a further eight have committed more than 50 changes. The top ten contributed 68% of all commits, Lubos alone contributed 28 % of all commits. Matthias Ettrich is with 4 % of all commits still in the top five. What really surprised me is that I already contributed 11 % of all commits and Hugo only working on the Oxygen Window decoration is third most active KWin developer – over the complete history.
Now the data is not perfectly accurate. KDE switched the version control system twice and the different VCS bring different patterns of work with them. Due to the bad branching feature of SVN large parts used to be developed outside of SVN and committed as a large bump. This is not the case any more with git: you have all commits out in the open. As at least I have been using git-svn bridge for quite some time, it’s not that surprising that I already have a large number of commits.
Now I had my tool to parse a git history into a statistic diagram and I thought what would be more fun than to compare the history to the one of another big window manager and compositor? So I dared to run the script on the Compiz history. The history in general is not comparable or more to say: it’s just numbers, it’s not possible to draw any conclusions from the history for comparing Compiz and KWin. Here are a few of the reasons:
  • The Compiz history only dates back to February 2006. According to Wikipedia Compiz was first released in January 2006. So some history is definitely missing.
  • Compiz had a vivid history. It was forked to Beryl, re-merged to Compiz Fusion, re-merged to Compiz, rewritten as Compiz++. I have no idea if the complete history of the forks is present in the repository.
  • Compiz has many, many plugins not living in the main repository. It is a question whether those have to be honored. KWin in comparison has all (with a minor exception of two or three effects) effects in the main repository.
  • KWin includes complex window decorations (c.f. the number of commits by Hugo) while Compiz includes wrappers around KWin’s and Metacity’s decoration. The theme engine for Compiz (Emerald) seems not to be part of the main repository.
  • Compiz code repository is split into several repositories. Here again the question which should be included into a comparison.
  • KWin is part of the KDE Plasma Workspaces, which gives us a slightly different development focus and the helping hands of many developers correcting common mistakes (e.g. i18n).
Given the constraints I decided to combine the history of Compiz core and of all the plugins in plugins-main. First again a look at the years:
We see that Compiz had a really strong start. In 2006 and 2007 Compiz had each time around twice as many commits as KWin, the difference is fading out lately. In 2009 KWin had more commits, in 2010 it’s very close and during the first three months of 2011 KWin has clearly more commits. What looks really bad in the Compiz graph is the loss of developers. In 2007 54 developers contributed to Compiz, in 2009 just 14. This illustrates the challenges Compiz faced in the beginning of 2009. At the end of 2008 the number of commiters per month dropped below 5!
Altogether Compiz had 92 developers. Three (David Reveman, Danny Baumann and Dennis Kasprzyk) have more than 1000 commits and make up more than 63 % of all commits. Compiz has only 7 developers with more than 100 commits and those 7 developers contributed more than 88 % of the complete code base. Only four more developers contributed more than 50 commits. Adding those we come to more than 92 %. Now to illustrate the problem I see here: David Reveman who is the initial author and holds 25 % of all commits did his last commit to the core repository in December 2007, Danny Baumann (number 2) in November 2010 (but  seems to be still a regular contributor) and Dennis Kasprzyk in April 2010. Of the last 500 commits 392 have been done by Sam Spilsbury. This looks like a bus factor of 1 🙁 For KWin I have 265 of the last 500 commits, though this includes the GLES port with more than 100 commits for itself.
Now I have one more graph I want to show: it includes the commits and authers per month and the accumulated number of commits.
Commits and Developers in KWin and Compiz per Month
The start Compiz had is really impressive. In a very short time they had almost as many commits as KWin had collected in the many years before. The graph is unfortunately difficult to read as it has a great variance between the months. Nevertheless it highlights the strong momentum Compiz had after the launch. In a few months Compiz had more active contributers than KWin and significantly more commits. In August 2007 Compiz reached a maximum of 415 commits! Unfortunately for the development Compiz failed to keep the momentum and both number of commits and developers seems to fade out.
[1]: All KWin commits are without scripty commits. For formatting the git log I used:

 git log –format=format:”%ad %h %an” –date=short –no-merges

My application parses the output and counts the commits per months, the developers per month and the commits per developer. All shown diagrams have a logarithmic scale in y direction.

=-=-=-=-=
Powered by Blogilo