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.
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.
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 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).
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:
And for OpenGL ES:
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.
Powered by Blogilo