The state of KWin
kde at martin-graesslin.com
Sun Dec 26 14:19:37 CET 2010
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.
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.
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.
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
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 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.
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
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.
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
*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
So that's it. Plasma devs I would like to have some feedback :-)
Happy and successful new year to everybody
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 316 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101226/0bdb036f/attachment.sig
More information about the Plasma-devel