Monthly Archives: February 2011

Fortschritt im Land der Wabernden Fenster

Ich hab schon länger nicht mehr auf Deutsch gebloggt, was natürlich nicht bedeutet, dass die Entwicklung an KWin eingeschlafen wäre, nein ganz im Gegenteil. Aktuell passiert im Land der wabernden Fenster recht viel und viele Verbesserungen für die Anwender sind in der Implementierungsphase für die nächste Version der KDE Plasma Workspaces.

Über die letzten Monate habe ich hauptsächlich an der Portierung von KWin nach OpenGL ES gearbeitet, womit KWin nun auch auf mobilen Endgeräten verwendet werden kann. Vor kurzem hatten wir dazu eine Meldung auf der KDE Nachrichtenseite (der Artikel enthält auch zwei Videos!). Was aber noch viel wichtiger ist als die Verfügbarkeit von KWin auf mobilen Endgeräten, ist dass mit OpenGL ES der Grundstein für KWin mit Wayland gelegt ist. Wayland erzwingt für Compositing OpenGL ES und somit muss jeder Compositor OpenGL ES verwenden.

Durch die Unterstützung von OpenGL ES wurde der gesamte Compositing Code überarbeitet und KWin unterstützt nun OpenGL 1.x und 2.x als rendering backends. Voreingestellt ist dabei (sofern es der Treiber unterstützt) OpenGL 2. Damit haben wir nicht nur einen bedeutend moderneren Code, sondern auch bessere Performance im gesamten Rendering Stack. Natürlich ist das noch nicht alles, denn wir arbeiten nun daran den Code zu optimieren und selbst ohne Optimierung spürt man schon deutliche Performance Verbesserungen im Vergleich zu 4.6.

Abseits der Programmierung passiert auch richtig viel. Ich habe angefangen im Community Wiki eine KWin Sektion einzurichten um neuen Entwicklern das Leben einfacher zu machen und unsere Bugzilla Komponenten wurden erweitert und die Bugs werden nun besser kategorisiert. Hier ist natürlich die Hilfe der Community mehr als erwünscht :-) Bei über 400 Bugs ist das kaum etwas was sich leicht und schnell stemmen lässt.

In unserer Code Struktur arbeite ich auch daran die Effekt API etwas zu erneuern um in Zukunft vielleicht doch irgendwann mal eine stabile API zu haben. Das ist eine Voraussetzung um einige Effekte aus KWin auszulagern. Mittlerweile haben wir mehr als 40 Effekte was sowohl uns als auch den Nutzern die Verwendung erschwert. Ziel ist es in KWin nur noch die wichtigsten Effekte zu haben und den Rest auszulagern. Dies erlaubt uns die Effekte besser zu warten und uns gezielt auf einige Effekte zu konzentrieren.

Demnächst beginnt auch wieder der Google Summer of Code und KWin möchte sich auch daran beteiligen. Wir haben einige interessante Projekte ausgeschrieben. Z.B. eine Modularisierung von KWin Core zur besseren Wartung von KWin Core, dem Aufbau eines Unit Test Frameworks mit Xephyr und KWin’s Scripting Komponente sowie ein Projekt zur Initialen Unterstützung von Wayland Clients. Natürlich kann jeder potentielle GSoC Student auch eigene Ideen bringen.

Wie man sieht sind wir fleißig am Arbeiten und wollen mit KWin in 4.7 das nächste Level des composited Window Managments einläuten. Die Änderungen sind jetzt schon unglaublich performant und meine Erwartung ist, dass wir mit 4.7 den Vergleich mit Compiz endlich nicht mehr scheuen müssen ;-)

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

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

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