Posted on

Why Breeze is not the default window decoration

This week we finally released Plasma 5.0 including KWin 5.0 and also a new design called “Breeze”. While Breeze provides a window decoration, KWin still defaults to Oxygen and that’s for a good reason. As I had been asked quite often why that’s the case and on the other side got lots of feedback from disappointed users using the Breeze decoration I think it’s needed to explain in a blog post the technical background.

I start with explaining how our window decorations work in KWin 4. KWin is a so-called re-parenting window manager. This means the managed X11 window is put into another X11 window providing the windwow frame. In KWin we use a QWidget for the window frame. Thus we are also restricted to what QWidget provides us. Our window decoration API predates the Compositing support and this adds quite some restrictions to it. Our solution is to intercept all paint events on the decoration’s QWidget and suppress it, trigger a repaint of the compositor and in the rendering pass ensure the decoration widget repaints to a temp image which then gets copied into a texture to be rendered by the Compositor.

The Breeze window decoration theme is based on the Aurorae theme engine. As I’m the main author of Aurorae I can bash it in this blog post without feeling sorry about it 🙂 Aurorae was designed to make it very easy to style a decoration and to make use of the new added translucency features. Being a solution which could be used as a default decoration was never the aim. The idea was to allow users who want the customizability this feature while the majority of the users could use the faster native themes. Aurorae was never fast and will never be fast. Over the time the performance improved, especially thanks to using QML. But also in that case it was only usable with the raster graphics system in KWin 4 times.

Now in KWin 5 the usage of QML is the main problem which makes it difficult to use Aurorae at all. QtQuick uses the SceneGraph and uses QWindow instead of QWidget. That’s quite a bummer for our QWidget based API. We adjusted the internal usage to support QWindow based decorations but that was quite a tough road as there are differences in the behavior of the windows. As it’s no longer QWidget based our interception of paint events is broken and we needed a new solution for it. And this solution is even more ugly than the old one because QtQuick is nowadays rendering through OpenGL. Due to limitations in Qt’s OpenGL implementation (might be addressed in Qt 5.4) we cannot share with the OpenGL context used by QtQuick. But we need to get the content from the Aurorae window into our OpenGL texture. The solution is to render to a QOpenGLFrameBufferObject and read it back into a QImage just to upload back to a texture. Not only is this a huge overhead to copy the content from GPU to RAM and back to GPU it’s also wasting lots of memory. The frame buffer object has the same size as the window and that’s way larger than the actual window decoration. In case of a maximized window it’s not just the title bar area but the complete window. And that overhead exists for each window.

That alone might render Aurorae completely unusable. I’m currently using the Breeze theme and KWin needs more than 200 MB of RAM – not really acceptable. But the situation is even worse. With QWindow we don’t get to know which areas got updated. So whenever e.g. a button gets updated we have to repaint the complete window including the complete copy of the decoration content. Which especially in animation situations is quite a problem.

The last problem to mention is OpenGL. QtQuick is supposed to use a dedicated rendering thread, but Qt disables that for all Mesa drivers and instead uses the main thread. But that’s also the thread KWin’s compositing OpenGL context lives in. That’s quite a performance problem and also introduces lots of instability problems (might also be addressed in Qt 5.4).

Overall the situation is so bad that colleagues recommended to disable Aurorae overall in the 5.0 release. As we released with it you can see that I disagree in that point. There is hardware where it’s working quite fine – on my system it doesn’t matter that it uses lots of RAM and if your driver supports Qt’s threaded rendering the performance problems are mostly gone and also all stability problems are gone. So the situation hasn’t changed: for users who want to customize there is a solution but it might introduce a loss of performance. But as a default theme like Breeze it’s clearly not an option.

So what’s the road forward? I started implementing a new decoration API removing the restriction of the decoration being QWidget based and at the same time I started implementing the Breeze decoration with this new API. I hope that we can introduce this in KWin 5.1. I’ll write another blog post about it soon and also prepare lots of small and easy tasks for new developers to join in this effort and help making a kick-ass decoration solution for 5.1

Posted on

QML Support for Window Decorations

Implementing a new window decoration for KWin is not the easiest thing to do. While the API has hardly changed since early 3.x releases it is not very Qt like and requires a strong understanding of how the window decoration in KWin works. To design a window decoration you basically have three options which come with KWin:

  • Subclass KDecoration
  • Subclass KCommonDecoration
  • Design an Aurorae theme

KDecoration gives a developer the most powerful options. The developer can design the decoration in whatever way he likes. But it also means that the developer has to take care about everything himself. E.g. properly laying out the buttons, handling mouse events on the decoration, ensuring the right resize handles are shown, etc. etc.

An easier way is to implement KCommonDecoration which already implements the common aspects of a decoration. For example a normal decoration has some buttons on the left and some buttons on the right side. The main task of a developer is to define how large various parts of the decoration should be, e.g. the margin between the left buttons and the caption. This of course limits the possibilities with the decoration.

The third option is to design an Aurorae theme which means just creating a few SVG elements. This is of course for designers the best option, but again very limiting. If a feature is not provided by the theme engine it cannot be represented. In the same way there are third party deKorator themes available.

The C++ based decoration APIs seem to be too difficult to be used. If we look at kde-look we see that there are just 14 native decorations available and some of them are forks or old versions of decorations available in KWin directly. But there are already 79 Aurorae themes available and more than 150 deKorator themes.

What seems to be a real issue concerning 3rd party usage can be validated if we just look into the KWin source base. In 4.9 we ship four window decorations: the Aurorae theme engine, Oxygen, Plastik, b2 and Laptop. Together they are 10 kSLOC of C++ code and 1 kSLOC QML code (Aurorae). Before Aurorae got ported to QML the size of the decorations was 13 kSLOC. Overall that is about 10 per cent of the KWin source base, which is rather large.

When I ported Aurorae to QML one of the nice results was that I had to add a QProperty based API to communicate with QML in the first place. If this were the actual API writing a window decoration would be probably much easier. As a first step in that direction I started adding generic QML support to Aurorae.

Following the general direction of all scriptable elements in KWin I decided to go for the well known Plasma Package structure, and added support to Aurorae to use a QML file from a package instead of the own QML file. The patch for this had been in my workspace for quite some time but I did not have any code to actually test whether it works.

So yesterday I started to re-implement one of our C++ based decorations in QML. I decided for Plastik as the decoration is in fact broken and had been scheduled for removal. We have not yet removed it as we acknowledge the user’s wish to have the KDE 3 look still around. But we are unhappy with having a decoration which is broken and unmaintained. So having a QML replacement would be something rather nice.

After one and a half days of work I’m proud to say that writing decorations in QML is possible. The changes to the configuration module and Aurorae itself are already under code review, the new Plastik still needs some love. But the decoration is already completely useable as can be seen in this screen shot:

In the current state the decoration consists of 370 lines of QML code and I expect to need an additional 100 lines to finish the buttons (they are already functional, that is the close button closes the window) and add some of the configuration options. The same API in C++ consists of 1500 lines of code. So we do not only get fewer lines of code but also a more readable and easier to maintain codebase. For something like a window decoration a declarative approach is much better suited than the imperative C++ way of painting elements.

Overall the new QML API will provide the same powerful features as the KDecoration API, but also provides convenience functionality as KCommonDecoration, e.g. a button group taking care of laying out the decoration buttons. To make development of QML based decorations quite simple support is currently being added to Plasmate as part of the Google Summer of Code project. So you will be able to design and also test the decoration directly from inside Plasmate. This is also quite some improvement as with C++ the only way to test a decoration is to use it in KWin, which can be quite nasty during development.

The API will need some more love till I’m quite confident to provide it’s usage but there is enough time till 4.10 🙂 So I hope that we can provide a better decoration experience in 4.10. I have a few ideas concerning the usage of QML based decorations in KWin and are looking forward to experiment with them.

Posted on

Aurorae 3: Window Decorations with QtQuick

Once upon a time there was a window decoration which was KDE’s default decoration. But years ago it fell into a deep sleep. The world changed while the decoration slept. Compositing was added, decorations received shadows, Qt introduced the graphics system raster and many many more changes.

Now after years the decoration temporarily woke up, but it is no longer a beauty, but ugly and old. The changing world made the decoration break. The decoration’s bits started to rot and this is visible. The truth is that the decoration will stay in the broken state as there is nobody who would want to fix it or anybody knowing the code.

What I just highlighted here is true for basically all old decorations. Of the decorations we ship only Oxygen and my theme engine Aurorae are maintained. This is a situation which can no longer continue. We have to face the truth and remove all old decorations.

But of course we don’t want to remove decorations without adequate replacement and this leads us to the story of Aurorae.

Aurorae was written to experiment with new features introduced in KWin 4.3. It was based on our common decoration API and by that is rather limited. So for 4.5 I decided to port it to the generic decoration API and reimplement with GraphicsScene instead of QWidgets. Aurorae allowed to download decorations through Get Hot New Stuff.

But given that it is a theme engine the possibilities are still very limited. Only what the theme engine supports can be rendered. Porting our old decorations to the theme engine might not be possible and not to be recommended.

But still we would like to have those decorations on a modern basis without the maintenance costs. So I started to port Aurorae to QML. This does not only give us a more powerful theme engine but also introduces QML bindings for window decorations, allowing everybody to write decorations with QtQuick.

So we can write themes without the limitations of a theme engine 🙂 This does not only remove 3000 lines of C++ code and replaces it by around 1000 lines of QML code, but also gives us an interactive decoration control module.

Interactive decoration control module

For Aurorae based themes all the buttons are interactive giving our users the possibility to really try the decoration before using it. But that’s not where it will end. I want to have new themes not based on Aurorae but using QML directly. For that I want to use the Plasma Package structure and would love to see integration in Plasmate. Another idea is to support deKorator themes inside QML.

But as always this does not come without disadvantages. Not all features which were possible with Aurorae will be available in Aurorae 3. Some features will also be dropped because hardly any theme makes use of the features, for example special backgrounds for non-composited setups. Aurorae 3 will hardly work without compositing, so it might be that we will make it a hard requirement somehow.

I hope to see many innovative QML based window decorations in 4.9.