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
Very informative, thanks. This made me wonder, and I tested on my system : gentoo amd64, Qt 5.3.1, kde framework 5.0 final, plasma 5 final. I got two big displays connected to a AMD RS880, and I use 4 virtual desktop (not sure it matters).
I looked at the “resource” column in top for kwin_x11. It takes
* 111m with breeze
* 178m with oxygen
* 100m with plastik
well Oxygen is not the memory friendliest either – all those shadows… Plastik and Breeze are pretty close to each other as Aurorae themes.
Nicely explained, thanks 🙂
But why does Qt limit multithreading on Mesa?
short story: crashes.
Well, Mesa is a software render, it’s no surprise…
It kills the peformance and the CPU…
But I am not sure if the awful performance is the reason of blocking it.
Mesa hasn’t been a software renderer for quite some time. It’s also a software renderer, but it’s also the driver for most hardware.
I will use kde when I can use a good theme, for now I can only say that oxygen is horrible :/
Bad luck for you.
not bud luck, there is a big and fantastic world with fantastics windows themes in linux, for other desktops environments :).
Well, yes, Plasma is the least customizable from all them…
KDE has a reputation for being non-customizable, so, seems like you are really out of luck…
HAHAHAHA… Agree with Martin.
Hey Martin, I have a doubt that .. You can not do a native Breeze theme as is Oxygen?
I think it had gone Plasma 5.0 later this year or early 2015. No offense, but to me is still in development phase this new version.
You should’ve read the .
Hey Martin, thanks for laying out the details for us and for all the hard work! It looks like an interesting and potentially frustrating problem. Let’s hope for all the pieces to fall in place for latest releases.
I’m digging this very informative blog.
I hope that these issues get solved in both Qt (5.4 hopefully) and in KDE. It looks like there’s multiple problems converging on this one issue.
That’s very informative Martin, I thank you very much for your post! Now what exactly do you mean by “The Breeze window decoration theme is based on the Aurorae theme engine…”? Since Aurorae isn’t suitable for “default” decorations and Breeze was created as the new “default” decoration, there’s something I’m missing…
I get the feeling that the current Breeze implementation is just a proxy/placeholder/testing mockup built under Aurorae for convenience of the developers (which actually makes a lot of sense). Is that correct? The “real” Breeze is yet to come?
yeah, you got that right. The current theme is kind of a working mockup.
Thanks for explaining Martin. Though, using a mesa driver (intel card) only having 4 gig ram (which isn’t that much) AND using dual screen, I had no real problem with breeze (at least it didn’t feel slower than oxygen). Though, I should hit all the problems described. Well… it did crash once… but I could not reproduce it ;D.
Went back to kde4 though, couldn’t package some of the stuff properly, so I decided to wait for official arch packages.
yeah for me it’s also working quite good on Intel, only the crashes are a huge problem (it happens on starting compositor if windows are already present, so e.g. restart of KWin can just crash).
I had a few crashes as well with the radeon driver, but the most annoying bug is that clicking on the window decoration sometimes doesn’t register and you have to keep clicking until it does. Or just click inside the window, that always works.
For a new Major KDE release you guys created a “default” theme which is basically unusable…is it April 1st already? Sorry, but… facepalm…
yeah it might look like this, just that the design team knew from day 1 that Aurorae is no solution for a default theme. It’s just a working mockup
Looking at it from outside it certainly does. This was not to blame you personally, btw. The team as a whole should have noticed, taken necessary actions and delayed the release if needed. I mean this is no glitch on the 3rd tab of some advanced config dialog, but one of the most important pieces of UI, directly in the face, not following the *new* default theme. Oh yes, memory and performance still *is* an issue on a lot of systems. But anyway, thanks for taking on and fixing this.
This was known from day one. You can ask for example Jens, we talked about it in the development sprint in January before the VDG was formed. It’s also what the VDG communicated all the time – the new design will come piece by piece and will not be settled with the 5.0 release.
Slightly OT, but since I read new API:
More and more DE’s are integrating the title bar better with the application, e.g. using the title bar for more than just the app-name.
GNOME went with client-side decoration, which apparently is a bad thing.
So I was wondering are there other (any) technical solutions in the KWin-team discussed for this IMHO very useful feature?
sure I did a serious of blog posts several years ago why one shouldn’t use client-side-decorations. Feel free to look them up.
… which doesn’t answer my question at all. 😐
jo! didn’t understand a thing but it sounds like this guy has enough knowledge to write a kickass new window decorator. Thumbs up for your work!