This week I finally moved kdecoration2 to the kde/workspace project structure and merged in the required backend code in kwin. This means the upcoming 5.2 release will ship with the new Breeze window decoration by default.
Thanks to the usage of the new library we get a nice performance boost in KWin. Some of this I already explained in my blog post announcing KDecoration2. The huge advantage here is that we do no longer use a QWindow as a backend and only require to hold an image the same size as the decoration. But there are more nice improvements around it. When I started designing KDecoration2 one of my aims was to focus it more on the use cases of a composited setup and design the API in such a way that a default decoration could be more efficient. Our previous default decoration Oxygen was rather heavy and KWin was not able to provide features to Oxygen which would make it more efficient. From a memory point of view the main issue with Oxygen were the shadows. With the old decoration API the shadows were part of the decoration. So the renderer got one big image for the shadow and the decoration part. But the shadow is the same for all inactive windows and could be defined by a much smaller image (lots of information is redundant). For KDecoration2 I looked at our existing shadow sharing mechanismn on X11 level and adopted a similar API which allows to provide a compressed shadow to the compositor. That way the shadow is no longer part of the window decoration and does not need to be part of the OpenGL texture. Of course this comes at the cost of needing more rendering calls (I deliberately moved the Time-memory-tradeoff towards better memory usage).
The real improvement comes when the decoration plugin can share the shadow between the decorations. This is being done for Breeze: there is never more than one shadow being created. In Breeze the shadow always has a size of 60×60 pixels, so we save 3600 pixels per decorated window. This is in addition to the saved memory for the compressed shadow instead of having the shadow as part of the window.
Today I went a step further and also modified the code in our OpenGL compositor to share the textures being created for the decoration shadow. So if two decorations have the same shadow, they will also use the same texture. This does not only save us some texture memory, but also means less pixel transfers from CPU to GPU. So a rather nice improvement. For our default decoration Breeze this means that only one shadow is created in the decoration plugin and also only one OpenGL texture needs to be created.
Unfortunately not all decoration plugins can benefit from this change. Also with KDecoration2 the problems outlined for Aurorae still exist and the change in the shadow mechanismn doesn’t improve the situation. The hope to improve this is in Qt 5.4 which gives us new useful features like QQuickRenderControl which allows us to integrate the OpenGL context used for QtQuick with our compositor’s OpenGL context. The hope is that we can render the QtQuick based decoration into an FBO and share the texture with our compositor, so that we can just bypass the normal decoration rendering process which is too costly in the case of Aurorae. I already switched the normal rendering to QQuickRenderControl if kwin is compiled with Qt 5.4 and the result is looking rather promising. Still the memory usage and performance of Aurorae will never be as good as the memory usage and performance of a native decoration. This has never been the aim of Aurorae.
> only require to hold an image the same size as the decoration
Oh, my impression was that we use only four “stripes” per window when changing the paint call from QRegion to QRect.
yes, that’s what I meant with “same size as the decoration”
This is probably a naive/open-door question: can/will anything of this be backported to kde4?
no, it’s using too many Qt5 features.
Thanks for your blog post as always !
“That way the shadow is no longer part of the window decoration and does not need to be part of the OpenGL texture.”
Does it mean that client-side-decorated or borderless windows (such as Steam) can finally have shadows in KDE ?
They could have had for years. We have a shadow mechanismn in place which gets for example used by the Plasma Dialogs and Panel.
Will the plasma 5.2 release will use Qt 5.4 or we will have to wait until plasma 5.3?
Not decided yet.
Thanks for the post, it was interesting as always.
Will there be a command line interface for themes? I would like to be able to setup a default desktop for a user when I create one, at the moment this seems to involve copying a partial ‘.kde’ folder into their home directory.
all config options can be modified using the command line – see kwriteconfig5
So for clarification, is Breeze still using Aurorae for a backend/and thereby hindered by Aurorae’s issues — for instance https://bugs.kde.org/show_bug.cgi?id=340116?
Breeze is now ported to KDecoration2 and no longer using Aurorae.
The time-memory tradeoff for reusing shadow textures is not quite balanced, in a good way: Since GPUs are made for rendering order of magnitude 100 million vertices per second (let’s say 1 million per frame), and tens to hundreds of textures per frame, the extra time needed should be tiny. It might even be faster to reuse the shadow textures because the total working set size and maybe (due to cache) graphics memory bandwidth requirement should go down.