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

Is KWin rocket science?

This weekend I played around with adding a slight animation to the BoxSwitch effect when the selection changes and when new windows are opened or existing closed. Here’s the video (sorry for bad quality):

(OGG Video)

The BoxSwitch effect is now animating the selection when pressing Tab. It’s moving instead of jumping as before. Another change is that all thumbnails adept to changes in their geometry when a new window is added or an existing is removed. They slide to the new position instead of just jumping there. Isn’t that elegant?

On this effect I worked together with a new possible KWin developer who does not know anything about OpenGL. So what do you think how many lines of OpenGL code this new animation contains? 100? 50? 10? or maybe 1? No you don’t need to know any OpenGL to write hardware accelerated animations in KWin. The complete animation code is part of the KWin animation framework and the only change to the code is adding a QTimeLine to the changing geometries. It’s currently just playing around but my plans are to add this new implementation into the rendering engine, so that any changing geometries are automatically animated without the effects to need to worry about.

What I want to highlight is that it is really easy to work on KWin. It’s not rocket science and you do not need to know anything about OpenGL to get awesome effects working. Our effect framework completely abstracts the dirty details making it easy for you to write awesome animations fast. There are lots of small things like here the BoxSwitch where improvements are more than welcome. Just come along to the #kwin channel, drop us a mail on kwin@kde.org and have a look to the Plasma Task Wiki page, which will soon be filled with KWin tasks, too.

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

Posted on

KWin and the unmanageable combinations of drivers

This week I once more noticed the biggest problem of KWin development: the differences between the multiple drivers. Since Monday KWin uses a new OpenGL 2 based coding path as default. The code was mostly written on one of my systems with the nouveau driver and regression testing was mostly done on my second system using fglrx which only supports the "legacy" old coding path by default but can be forced to the new one (but too slow for productive usage).

Around Wednesday notmart reported that the code is broken on NVIDIA proprietary driver. As I had developed on nouveau I had not tested with the blob. So I had to switch the driver again and could confirm the regression (after fixing: it was clearly our bug and not NVIDIA’s). The regression occurred in a code path which seems to be only executed with the NVIDIA blob. It took me hours to figure out what is causing the bug and how to fix it. And it illustrates the big problem in KWin development: without an NVIDIA card and the driver I would not have been able to fix it and I doubt that anyone not knowing the code would have been able to fix it.

Currently KWin supports hardware from the three big vendors: NVIDIA, ATI/AMD and Intel. Each of the vendors has a set of different hardware generations. The biggest difference is between the fixed functionality hardware and the general purpose GPUs. The difference between the hardware generations is so big that assuming that just because it works on one of it, that it works on the others, too, is rather naive.

So we have different hardware vendors with hardware in different generations. Let’s make it more complex: drivers. We also have different drivers for the same hardware. Currently we see the following drivers:

  • NVIDIA proprietary driver
  • Catalyst (aka fglrx) proprietary driver
  • Intel (Mesa driver)
  • Radeon (Mesa driver for AMD/ATI)
  • Radeon/Gallium3D (Mesa driver for AMD/ATI)
  • Nouveau (Mesa driver for NVIDIA, Gallium3D, experimental)

Except for Intel we have different drivers for the same piece of hardware. In case of AMD/ATI even different free drivers (the list is missing radeonhd). The big hope is here in the Gallium3D stack which will hopefully simplify the situation by having one free stack shared by various drivers. As my example above illustrates different drivers for the same hardware show different behavior. So we need not only test with various hardware, but also with the various drivers. So at that point we are somewhere around 30 to 50 combinations of different vendors, hardware generations and the drivers for them.

That’s quite complex already, isn’t it? So let’s make it more complex: driver versions. Obviously each vendor/driver developer is working on their drivers and is fixing bugs and introducing new ones. Of course we need to support all versions properly, so we would need to test with all driver versions. E.g. we know that we see regressions in the latest NVIDIA blobs. Unfortunately I’m still on an older one due to using Debian Testing and not wanting to mess with my setup. So I cannot investigate these issues.

Ok we just made everything more complex with driver versions. Let’s add another complexity factor for the free drivers. The free drivers are more or less bundled together with libdrm, mesa, XServer and the kernel. Some drivers require a specific kernel version or won’t work with another one. This is kind of opening Pandora’s box concerning the possibilities of combinations.

So we have reached the level of combinations which are not being possible to test without recompiling the complete kernel/mesa/X stack. Let’s add another complexity factor: distributions. Distributions do not only ship the upstream drivers, no they "improve" them. We have seen that in the past several times that distro specific code broke KWin. The distribution tries to support a vast diversity of software and it can happen that an optimization for Compiz causes rendering issues in KWin. Also distributions sometimes bundle combinations of drivers and kernel which do not work together. This mostly happens with rolling release distributions. E.g. new Mesa version requiring a new Linux kernel which is not yet released. But rolling release distributions like Arch are also hitting problems before other distributions which can help us to workaround issues before it hits distributions with a larger userbase such as Kubuntu or openSUSE.

All together there are several hundreds of combinations of the stack below KWin. Changes in any of the component can cause regressions. Even trying to test all of them seems to be ridiculous. If I would try to test a reasonable amount of the combinations (vendors * hardware generation * drivers * latest version) I would need something like 30 machines. Of course I don’t have the time for it and that’s also the reason why I declined all hardware offerings so far. It’s just like a drop in a bucket.

But we have users who can test. We need users willing to run the latest KWin master together with the latest driver versions to ensure that we do not run into regressions. And we need users reporting high quality bug reports who are willing to also report them on freedesktop.org bugtracker.

And we need developers: preferable with OpenGL experience. Now is the perfect time to join the KWin development. We switched to a more easily readable coding style and introduced a new and modern OpenGL Shader based compositing backend. You could work on improving the User Experience for all users by writing more awesome effects or optimizing our backend. It’s really fun stuff.

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

Posted on

On the Road to Modern OpenGL (ES)

With KWin GLES shortly before the merge into workspace master (after git transition), it’s time to look back what I promised to deliver half a year ago, when I first talked about the idea of porting KWin to OpenGL ES at Akademy.

At the time of Akademy I had not yet started to write any code as I considered 4.5 more important and waited for the git transition. Obviously I stopped waiting for git or there would not be any code written 😉 My schedule presented at Akademy looked like that:

  • Remove deprecated OpenGL code
  • Remove unused code in Scene and E?ects Lib
  • Drop XGL support
  • Port to OpenGL ES 1.1 till 4.6
  • Port to OpenGL 3 and ES 2.0 till 4.7

Removal of deprecated OpenGL code is mostly done. With GLES KWin has a forward compatible code path, though we still have OpenGL 1.x code for legacy systems and that won’t be dropped in the near future. Considering deprecated OpenGL 1.x code it’s looking quite good, e.g. glBegin/glEnd is removed in the GLES branch. Rendering of geometries is abstracted and the backend performs a runtime check whether legacy or modern rendering is invoked.

For 4.6 I started to port some effects to newer functionality which allowed to drop some then unused code. The remaining functions have been marked as deprecated, but are not yet removed in the GLES branch as they are still used by the Shadow effect (though unavailable in OpenGL ES and broken with OpenGL 2 backend). Given that Shadow is difficult to port, in general broken and unmaintained I consider to just drop it. I am already gathering ideas for a new replacement effect.

The XGL code (XGL was needed to run Compiz before AIGLX was integrated) is still in KWin and should really be dropped. It has been removed from X git tree for quite some time and I doubt anybody has ever run KWin with XGL. There are more things we can now consider to remove: shared memory and "fallback" compositing. Together this will mean a requirement to Texture from Pixmap. That’s pretty well supported nowadays on all drivers and anything else cannot be recommended.

The next bullet point is OpenGL ES 1.1. Well I noticed that it would really clutter the code, so I stopped working on it and switched to going to ES 2.0 directly. My initial plan was to provide 1.1 support at the time of the 4.6 release. Instead we now have ES 2.0 support at the time of 4.6 😀

In 4.7 we will not only have an OpenGL ES 2.0 backend available, it will be integrated into the release. As a side effect it gives us a complete OpenGL 2.x backend which should benefit all users having decent drivers. I’ll soon integrate an option to the advanced settings tab to choose between OpenGL 1.x, 2.x and 3.x. With the 2.x code there, it’s really easy to go to 3.x. We won’t default to it, we will hardly use it (I want to experiment with Geometry Shaders in MagicLamp effect), but I hope that the drivers supporting OpenGL 3 (that’s for us only the NVIDIA blob at the moment, fglrx is only usable with OpenGL 1.x in the composited case) are more efficient if run in a forward compatible profile.

There is still lots to do and I want to concentrate on improving the rendering stack throughout the 4.7 release cycle. It’s quite fortunate that the new rendering stack can be integrated directly after the git transition. So I hope that lots of developers will be using it and can provide feedback for various hardware.

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

Posted on

Bug Statistics for KWin 4.6 Cycle

Once again I used Bugzilla to get some statistics on how many bugs are opened, closed in KWin during the last development cycle (statistics are from Final Tagging 4.5 till today). Overall 437 new bugs have been reported and 425 bugs have been "closed". Many thanks again to the bug day – without it the numbers would look worse. So this means that each day 2.4 bugs are reported. Assuming that we spent 10 minutes on each bug (in general Thomas Lübking and I are reading and responding to each bug comment), we spent 8 days just on bug managing. That sounds reasonable, but is very bad as it’s time spent managing and not fixing the bugs. This can be seen in the table below.

Like in my previous reports about 40 % (165) of the new bugs are duplicates. But this time we also faced the problem of the drivers: 12.8 % (56) of all new bugs have been marked as upstream. I also took the time to go through all duplicate crash reports and found another 52 duplicate driver crashes. About 50 % (213) of all bugs are crashes, but only 3 crashes are confirmed and only 9 have been fixed. 24 of the crashes have not been confirmed yet, meaning that the way to reproduce is not clear. Altogether 21.5 % (94) bugs have not been confirmed yet. Apart from the driver bugs our worst problem has been in Desktop Grid and those crashes were fixed early in the cycle.

Category # New Bugs/% to All # New Crashes/% to New Bugs Overall Closed
Unconfirmed: 94/21.5 24/25.5
New: 17/3.9 3/17.6
Needsinfo: 37/8.4 27/75 55
Fixed: 34/7.8 9/27.3 71
Invalid: 24/5.4 3/12.5 26
Wontfix: 2/0.5 3
Duplicate: 165 (-52)/37.8 110 (-52)/66.6 185 (-52)
Worksforme: 5/1.1 19
Upstream (driver): 56 (+52)/12.8 36 (+52)/64.3 63 (+52)
Downstream: 3/0.7 1/33.3 3
Sum: 437 213/48.7 425

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