The Compositing Modes of KDE Plasma Workspaces Explained

In the KDE Plasma Workspaces 4.7 we introduce new Compositing backends/modes in our Compositor. Lately I noticed that there is some misunderstanding on what are the differences between the modes, why we wrote new code and what is the best mode for whom (at least one distribution did it wrong in their first packaging approach). With this blog post I hope to shed light on the various modes.

OpenGL 2.x/GLX

This is our default compositing backend. It uses only the so-called programmable pipeline or also known as the “core” profile. For rendering we use only shaders written in the OpenGL Shading Language (GLSL) without making use of any fixed-functionality emulation code. For the interaction with the underlying graphics system we use GLX and the extensions for compositing. Namely the texture from pixmap extension to get an OpenGL texture from an XPixmap (the window content). As the code matches the core profile it would be easy to add “support” for OpenGL 3 or 4, just in case someone is wondering. But as we do not make use of anything provided by OpenGL 3, there is no need for this.

OpenGL 1.x/GLX

This is our legacy backend and the code we only had in 4.6 and before. The code uses only fixed functionality. Up to 4.6 it was possible to also use Shaders written in GLSL. This is no longer possible. Effects requering shaders may provide a shader using the ARB Shader extension which can be used only in this mode. The code to access the underlying graphics system is shared with the OpenGL 2.x backend.

The legacy backend is used automatically for all drivers not supporting at least OpenGL 2.0 and the fglrx driver. Furthermore there is an option to enforce this mode in the Advanced Desktop Effect settings: uncheck option “Use OpenGL 2 Shaders”.

OpenGL ES 2.0/EGL

This is the backend for the future. It’s primary target are mobile devices (Plasma Active), but also on the desktop it is very important as it is the requirement for supporting Wayland. Like OpenGL 2.x it uses the programmable pipeline and shaders written in GLSL. In fact the OpenGL ES 2.0 and OpenGL 2.x backend are identical to more than ~ 95 %. The difference is in the way how to access the underlying graphics system. Instead of GLX we use EGL and the EGL_KHR_image_pixmap to bind an XPixmap (window content) to an OpenGL texture.

In opposite to the other two OpenGL backends this one is not a runtime option, but a compile time option. OpenGL ES 2.0 is (mostly) a subset of OpenGL 2.0 without the legacy code. So the old code would simply not compile against the libraries and that’s why it is a compile time option. To enable use the CMake flag “KWIN_BUILD_WITH_OPENGLES”. Be aware that EGL is not supported by all drivers. To my knowledge only the Gallium radeon and nouveau drivers support it at the moment. This means especially for distributions: don’t use the build flag for the default package, but provide an additional one. For the next release cycle I hope to make it a runtime option.

XRender

XRender is a completely different backend. It can be selected in the advanced Desktop Effect settings in the dropdown “Compositing type”. Furthermore it is used as a fallback when the OpenGL backend fails in an expected way (e.g. Software Rasterizer). The XRender backend can only provide 2D animations, so e.g. no Cube effect. Performance on the backend depends on the driver, but can be rather fair (I once did not notice that the XRender backend was used in a virtual machine).

No Compositing

Not really a backend, but also a mode which has to be mentioned. KWin also supports no compositing at all. This mode can be entered at all time by the Shortcut Alt+Shift+F12 and in the General Desktop Effects settings through option “Enable desktop effects at startup”. Also at runtime self checks may disable compositing and also applications can block compositing bringing KWin into this mode. The Composited mode can be re-enabled through the same shortcut.

How To Notice which one is Used?

This can be quite tricky, because KWin automatically falls back to a different backend if one fails. E.g. if OpenGL 2 is not available OpenGL 1 is used. Or if OpenGL fails, KWin might fall back to XRender. KWin does nowhere log which backend is really used, but there are some messages printed to stdout which can help recognizing the version. KWin always prints out the used OpenGL version information. This looks for OpenGL like this:

To distinguish OpenGL 1 from OpenGL 2 backend there is one debug message related to "KWin::ShaderManager::initShaders". There should be three messages for valid - then OpenGL 2 is used or at least one message on failure, then OpenGL 1 is used. Recognizing XRender is even more difficult. In case that we face issues for debugging we will add more precise debug messages. Personally I test which backend is used by using functionality tests: the Cube Effect requires at least OpenGL and the Sphere and Cylinder effects require at least OpenGL 2.

Why a new Backend?

There are several reasons why I started to work on the OpenGL 2/OpenGL ES 2.0 backend. First of all we wanted to have support for everything which is nowadays known as Plasma Active, but also Wayland is very important on the longer term. Currently Wayland requires an EGL backend, so having support for EGL is a prerequisite. Last but not least to give our users the best possible performance and user experience. The programmable pipeline is a way nicer API to write GL code and especially the ES code can benefit users as it throws out all the legacy code and state tracking, which is rather complex in OpenGL and should ensure better drivers.

I tried kwin 4.7 (beta 1) yesterday on my laptop, with a nvidia Quadro FX770 (same as a GeForce 9600M GT) and the closed source drivers (275.09). For me some effects are not as fast as with 4.6, even when I disable the usage of OpenGL 2 Shaders. Especially the “minimize animation” is noticeably sluggish, when I unminimize a window.

Sliding down Yakuake is also stuttering. Especially when another window is openend. When I minimize all the other apps, the sliding down animation is a bit smoother.

As far as I know from your previous posts you are testing the OpenGL 2 ES mode on a nvidia based machine. Could you at least tell us a bit more about your configuration and experiences with GLES, nouveau and 3D performance?

my notebook uses a Nvidia Quadro NVS135M gpu and for quite some time (years?) I have massive slow downs in KDE4 (a lot of different nvidia binary drivers tested – and always using the latest KDE). Even disabling the KDE desktop effects doesn’t help, but telling the nvidia driver to clean it’s cache helps.

As you seem to be an KDE expert: Do you know about this problem? Will it be fixed with the new modes in KDE4.7?
Is it nvidias fault? The nvnews.net forum has some error reports like mine – but they (nvidia) never admit that the problem is real 🙁

of course we know about it and what might help is using graphicssystem raster with 4.7. Overall it seems to be the blob’s fault as we neither can investigate it (it’s a blob so no debugging) and it’s not present with any other driver.

Dell E6400 with Nvidia 160m here. I have been also feeling your pain too :-). I’m now running nouveau with KDE 4.6.3 (Arch) and performance has gotten better compared to the 4.5 cycle with Nvidia blob although most of the time I still disable Desktop effects since e.G dragging a window causes a delay

>but telling the nvidia driver to clean it’s cache helps.
how do you do that? When I was running blob I noticed that sometimes I had to switch off the computer and switch it on again to gain back performance so this might be related. I noticed the driver always reported the RAM with 512MB instead of the 256MB for my gfx.

No not likely, for what the benchmark tested, I expect that KWin 4.7 would do worse. But that’s exactly why I say that the benchmark has a systematic error. The performance depends on settings which are different between KWin and Compiz and in 4.7 we changed the default, so we behave like Compiz.