The state of KWin

[Martin Gräßlin]

Hello,

let me break the Christmas silence by writing a long post about the current 
state of KWin and where we are heading towards in 2011. As this also is about 
Plasma I sent it to both lists. I have been thinking a lot about the last year 
and the state of kwin over the holidays and here is the summary. Sorry that it 
is that long.

*Plasma and KWin*
I consider Plasma and KWin as the integrated product of the KDE workspaces. 
Both products depend on each other and do not make much sense without the 
other. This is also reflected when looking at our developer base: we have 
almost a 100 percent match. We currently see great improvements on the syncing 
of our working procedures. Using reviewboard, having common processes for git 
and so on. I hope with the switch to kdelibs coding style (scheduled for 
directly after import of KWin-GLES) and removing bug mails for KWin 
mailinglist to have improved the situation for Plasma devs. If there is 
anything from a Plasma perspective to improve it even more, please let me 
know, I am open to all suggestions.

*Driver situation*
We had a very bumpy ride with the 4.5 release. We introduced new (optional) 
hardware requirements which just failed with free drivers. We noticed too late 
that we had a problem and shipped with the broken setup. The last minute 
adjustments like the blacklist did not solve the issue at all.

4.5 showed that we have no way of testing KWin on a various set of hardware. I 
was able to test KWin on just one NVIDIA system at the time of 4.5. Nowadays 
it increased to three and soon will be four, but it's nothing. There are 
houndreds of combinations and we cannot even try to test them all. We need to 
raise the awareness that at least all KDE developers who run trunk have to 
report new introduced problems ASAP. I just cannot understand that problems 
like slowness of Present Windows with NVIDIA is reported by users in the beta 
phase several month after the code hit trunk!

Nowadays it looks better. The reports on broken drivers decrease and we have 
platform detection code and can now disable features for cards we know that 
they don't provide a feature even if the driver tells us it does. We do not 
make use of it, but I hope to see it used everywhere in 4.7 where we check for 
available features. For 4.7 we will see a new rendering path which has been 
developed using Gallium3D, so here we will also see more hardening and I want 
to submit our complete rendering engine as piglit tests.

*Elegance*
In the second half of the year the development focused on what Aaron would 
call Elegance. We were able to increase the performance significantly in many 
different areas. The new effects like dashboard, screenshot or startup 
feedback clearly fall into this category. I want to see this continued in the 
next year. KWin is a great window manager, let's smooth the rough edges and 
get the desktop use the advantages of OpenGL compositing.

*GSoC*
During the last two years we had two GSoC and one SoK projects. While they add 
great functionality they are a complete failure from a maintainance point of 
view. None of the developers stayed, the code is partly buggy and even crashy 
and in case of the JavaScript bindings we do not even have any documentation 
on techbase how to write scripts.

For the next GSoC I will not accept projects adding new features and I would 
prefer having students known to the KDE community (I am thinking about some 
members of the Plasma team here). We need projects which increase our code 
quality and not adding more problems.

*Manpower*
Manpower is in my opinion the biggest problem of KWin. We are just three 
developers + Chani and Ivan working on activity related code. I would like to 
get more Plasma developers working on KWin. It should be a natural thing to 
touch KWin code and to add new features in KWin if it makes sense. Here I 
would like to know from the developers sometimes working on KWin what needs to 
be improved. Where are things missing to grab the code more easily.

I am currently trying to recruit a new developer and I would like to see KWin 
having a fulltime developer - we have enough to work on. I at least plan to 
look into that topic in 2011.

*GLES*
The port to OpenGL ES is nearing completion. I will finish the port of cube 
(almost done) and leave out the remaining unported effects at the moment 
(mostly shader based effects like blur which need some more thoughts). I will 
switch back to desktop GL to ensure that everything is still working and then 
call for testers (depending how much spare time I will find next week it will 
be the next or the second next weekend).

GLES gives us a much more modern rendering backend which I expect to perform 
much better and gives us the chance to add more elegance to the desktop ;-) 
The improvements through GLES will also benefit desktop users using a modern 
enough driver. Unfortunately the decision whether ES or desktop GL is used, is 
a compile time decision and at least NVIDIA does not ship ES drivers. So we 
cannot depend on ES, nevertheless I will try to find a runtime detection 
solution.

*Modularization*
If we want to make KWin a real alternative on mobile devices we need to become 
more modular. This could be a nice GSoC project. Modularization is probably 
also a requirement for Wayland.

*Wayland*
The Linux desktop is standing in front of the biggest transition for years. 
Whether we like it or not, I expect that Wayland will come. Personally I think 
it's the right way to go, so we need to get ready. KDE is known to be early 
adopters of new technology and Wayland is an area where it really makes sense.

There a two ways to approach it: 
1. writing a new compositor
2. port KWin to Wayland

Both are valid approaches and have advantages and disadvantages. I think it is 
possible to port kwin and that it seems to be the better choice to go that 
path. We have hardly the manpower to maintain one window manager, I don't 
expect us to be able to maintain two window managers/compositors and we will 
have to keep the X backend for quite some time to go. Also I think that for 
our users a path of little steps inside KWin will be more smooth.

With Wayland many things have to be moved into the compositor, like what's 
today kdm, screensavers, etc etc. So we really need to get Plasma devs 
starting working on KWin ;-) On Wayland I will soon send another mail to the 
lists.

*Focus on Compositing*
Whether Wayland will be an issue or not, our focus has to be on the 
compositing stack. From a window manager perspective KWin is stable, feature 
rich and without many bugs. Our compositing backend looks pretty good nowadays 
and we have several unique features. I found many issues in the stack during 
the ES port and I will concentrate on fixing them. So to say: focus on 
elegance :-)

So that's it. Plasma devs I would like to have some feedback :-)

Happy and successful new year to everybody
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101226/0bdb036f/attachment.sig