Fallback mode in KDE Plasma Workspaces

Recently there has been a lot of buzz about non-composited fallback modes in various Desktop Shells and of course I have been asked several times about the fallback modes in KDE Plasma workspaces and whether they would be removed, too. Now instead of answering the same question again and again I decided to write a blog post to discuss the situation in more detail.

The first thing to notice is that KDE Plasma workspaces do not have a non-composited fallback mode in the way GNOME Shell or Unity used to have. The main difference is that our window manager (KWin) is able to act as a non-composited, XRender based compositor and OpenGL (ES) based compositor. This means that we do not have to maintain two window managers in order to provide non-composited setups.

The second major difference is that the Desktop Shell (either KDE Plasma Desktop, KDE Plasma Netbook or KDE Plasma Active) is not a plugin to the compositor but a separate application running in an own process. This allows to use a completely different window manager together with the Desktop Shell. Some years ago it was not that uncommon to use Compiz together with Plasma, though we see less and less such usage patterns (mostly caused by Compiz no longer being available in most major distributions except Ubuntu). This is a design decision which served us well and we do not plan to change it. Some time ago I brought up the topic, but more experienced developers (mainly Aaron) illustrated nicely the advantages of our design choices.

Of course we need some code to be able to adapt to non-composited mode inside the Plasma workspaces. But this code would be needed anyway. Why? To answer this question we have to go back in time to when the development of Plasma had started – that is around 2006/2007. Back then OpenGL based compositing had been a rather new topic (I think I first heard about Compiz in 2004 or 2005) and it had only been possible with the binary blobs and hacks such as Xgl. The Intel hardware back then was not powerful enough and drivers were lacking, too. With other words: going an OpenGL-based only path seemed not feasible at that time and consider that the fallback modes in Unity and GNOME Shell got only removed in late 2012/early 2013. This is more than half a decade later – an eternity in IT. Also KWin did not enable compositing support by default till 4.2, so the first releases of KDE Plasma were non-composited by default.

The solution inside Plasma was to make our themes aware of compositing. That is each theme contains an opaque element set which will be used when in non-composited mode. The fact whether compositing is used, is globally available through a standardized X11 manager selection. So whenever the compositing state is changed Plasma is notified and switches the used elements. Simple and elegant. This functionality served us quite well when we introduced the blur effect. Translucency is actually a very difficult topic. If you choose a too strong translucency level the text is no longer readable, if you choose a translucency fitted for text readability the translucency is hardly visible. The solution to this problem is the blur effect. It provides easily readable text even with strong translucency levels. But even today we do not enable the blur effect by default on all hardware as it is an expensive effect and we would not dare to enable it on embedded devices (personally I doubt that Windows 8 removed the blur because the designers disliked it). So we see we need themes with different levels of translucency depending on whether blur is available or not. The design decisions for the Plasma themes provided us the solution directly. As well it means that even if we would drop the non-composited mode we would have to keep our design to support the blur selection.

For most of the applications it hardly matters whether the desktop is composited or not. Only very few applications use the alpha channel in the first place and if they want to use it, everything’s nicely abstracted inside Qt.

Inside the window manager it also doesn’t really matter. Of course our window decorations are aware of whether compositing is used or not and especially Oxygen makes use of it by providing an adjusted look for the non-composited case, so there we have some overhead, but except that there are hardly any adjustments.

This also means that we would not gain anything from requiring compositing. The compositor is a separate module inside the window manager which just gets started by the window manager on start-up. It lives more or less for itself and is just notified when a new window is added to the window manager and so on. Nothing inside the window manager really depends on the compositor. That means it would be more work to get KWin requiring compositing than to keep supporting the non-composited mode. And having the non-composited mode around allows us to do things like turning compositing off when running games or heavy OpenGL based applications such as Blender. So if you want to get some of the now finally available games for Linux, KDE Plasma should be your primary choice to enjoy the game. I have also heard of users switching to KDE Plasma because we still provide non OpenGL based setups.

What remains is the question of what will change with Qt 5? Obviously not much. Plasma will continue to provide a non-composited and a composited theme, but Plasma itself will require OpenGL due to being based on QtQuick 2. I do hope that llvmpipe will be sufficient for Plasma in case of non available drivers. The same is true for KWin: our QtQuick based elements will require OpenGL 2, but that does not mean that we will require OpenGL based compositing. We will still provide non-composited mode and if the XRender based compositor get’s ported to XCB (we have lots of work there to get involved ;-) will continue to provide XRender based compositing as well as OpenGL 1 and OpenGL 2 based. Since the refactoring of the OpenGL based compositor I do not see much difficulties with keeping the OpenGL 1 based compositor around, though if it turns out to not be used anymore, it might be removed.

The last remaining question is what will change with Wayland? Obviously Wayland requires to have a compositor, but it does not require us to stop supporting X11. KWin will continue to be an X11 based window manager allowing you to not use Wayland at all. And even if you choose to use a Wayland based KWin nothing says that it needs to be a compositor on top of OpenGL. Whether we will provide non-OpenGL based compositors for Wayland is a question for the future, though.

A final remark: this blog post describes the situation inside the KDE Plasma workspaces and the design decisions we have done. This is not a critic at the design decisions other projects have done and I am not able to judge whether their decision is right or wrong and it is completely irrelevant what my opinion is on their decisions.

18 thoughts on “Fallback mode in KDE Plasma Workspaces

  1. This is essentially what I love about KDE – evolution rather than revolution. KDE doesn’t shock users with changes, both in term of usability and technology used.
    And when new ideas are added to KDE project, they are first optional.
    Kudos for that

    1. “I love about KDE – evolution rather than revolution.” except KDE 4 and bad PR people made about it…

      Anyway, hail to the king Martin! Great work as usual and from what I’ve seen Qt5 is back on the track so good news all over the place.

      Only complainant about we’re-awesome-without-compositing – I’m sorry but last time I checked it’s not so awesome, glitches all over the place (black borders, black corners etc). KDE is awesome but without compositing it’s looks much like a beta release. And your solution to that was… use compositing. So maybe oxygen use two different styles but non-composited version is not so polished as it should be. Anyway I’ve switch to compositing since my machines can handle it (kwin is faster and better with every release!). I disabled all of the oxygen animations and half of the default kwin effects (blur is just waste of resources). Now KDE is flying!

      ^ That’s its problem, most people can’t/don’t know how to tweak it and by default KDE is bloated as hell. But it’s another topic.

      End of rant. Keep working. Can’t wait for 4.10beta2!

      1. Depending on *what* is actually “black” this is not necessarily a problem in KDE/KWin/Oxygen/Plasma but in the X11 server because the server side backing stores are nowadays deactivated or not available (since the compositors basically serve the same job) causing “such” glitches on exposure events – notably seen with ARGB windows (plasma & plasma popups)
        Activating the backing store -if available- would fix those glitches that will also usually go with a call to “xrefresh”.

          1. A user? What are you doing using linux? Dig through the newsgroups/forums to find the answer, or through the code like the rest of us…this is how it has always been and always will be.

            :P

          2. Section Device
            [other options]
            Option “BackingStore” “true”
            EndSection

            And hope for the best. As mentioned, w/o precise knowledge about the actual issue it’s impossible to say whether that’s it at all.
            However if it works and you don’t intend to use compositing, having a serverside backing store is a good idea.

  2. Well, it’s nice to see we can always rely on Michael Larabel to turn an informative Blogpost into a Smacky Headline: “Why KDE Is Great For Gaming On The Linux Desktop”…

    I really don’t know if that is exactly what this Post ist saying, but hey, it sounds good! :D

    1. Rather annoying as that has not at all been the point I wanted to make. If I had expected that this sentence will be picked out I would not have written it.

      1. Why do you find it annoying? Being able to run the desktop without compositing can have implications for 3D applications such as games. It is a KDE feature which now separates it from Gnome and Unity. Sure, he spiced the story pitching you against the alternatives, but you have made it crystal clear in your blog that you do not intend to criticise the other desktops.

        I find it more annoying that hardly any other web-sites seem to find the story worthy of reporting.

        1. I find it annoying as it puts a light on the blog post I did not intend to have. The things I wanted to point out are how we handle the non-composited case, that this has some advantages is just a side-note.

          1. While I understand your view, I think it is pretty clear that the majority of users will be more interested in the side note. As such, a journalist should naturally bring focus to the side note.

            Personally, I am very happy to see journalists bring light to your blog posts, and I hope Michael will continue doing it :)

  3. Good to know the design decisions that motivated KDE to remain sane while the rest of the desktop world went reinventing what the user wants!

  4. The funny thing is that when one would need to fallback to llvmpipe (old machine or something new without GPU or without a GPU with drivers) the CPU power is in many cases just not sufficient.

    Like on Intel Atom (with dreaded GMA500 GPU), ARM etc.

    This makes KDE my preferred desktop on low end cpu’s as well. Precisely because you can turn off all the heavy stuff.

    I realy do hope other parts beside the compositor follow a similar alternative rendering strategy as does kwin.

  5. It’s nice that Plasma theme supports opaque style. If only theme developers actually bothered to look at their themes with compositing disabled…

  6. The earliest widespread implementations using this technique were released for the Mac in Mac OS X 10.2, and for Linux in a Luminocity prototype. Currently, window managers using OpenGL include Compiz, KWin, and the Quartz Compositor, while Desktop Window Manager currently uses DirectX 9. OpenGL is still not fully supported in hardware, so performance of OpenGL-based compositing should continue to improve as hardware improves.

Comments are closed.