PlasmaShell Sans GL

Since Plasma 5, the main shell is powered by QtQuick, which till now brings a requirement on a working OpenGL setup. This causes problems for Plasma in situations where we can’t run OpenGL; either extremely cheap hardware, xrdc or when a user upgrades and breaks their nvidia setup (a seemingly common occurence).

Qt 5.6 brings a new module which opens some interesting possibilities; the QtQuick 2D renderer, which avoids that.
This has existed for a while, but it has only recently been open sourced as GPL3.

QtQuick Internals

QtQuick is powered by a scenegraph.

Each graphical item updates a tree containing nodes containing either transformations or content. That content being either a rectangle, a picture or a custom openGL shader from the application. The important part is that it stores a tree of items in an way optimised for rendering, but also acts somewhat as an layer between any QtQuick component and the underlying OpenGL renderer.

Using the QtQuick 2D renderer

The QtQuick 2D renderer still uses the same scenegraph, so all custom QQuickItem’s which use the standard QtQuick SceneGraph nodes still work, but instead of calling OpenGL functions, calls are mapped to a raster backend instead.

The Result

My personal desktop, running Plasma using the QtQuick 2D renderer. The screenshot shows some of the parts working, but also highlights some of the bugs

Performance is surprisingly fast, not faster than the OpenGL backend, but plasmashell still remains perfectly usable on my desktop.

Most of the basic scene graph nodes have a 2d renderer implementation, however any node that does custom openGL, such as QtGraphicalEffects or certain parts of Plasma, will simply fail.

What’s broken

There are plenty of known limitations with using the 2D renderer, some cosmetic, some more fundametnal.
Qt provides their own list.

In terms of Plasma, the list of broken items are:

  • We have our own GL check in the shell that needs adapting
  • Icons were broken. We implemented our own shader whilst animating between states rather than uploading a new pixmap per frame. I fixed this by simply turning that off.
  • Our load monitor plasmoids are pure GL. I’ve made a patch that makes it not crash. Making it actually work would mean having two implementations…which isn’t a route I really want to go down.
  • Widget explorer is broken, again we have our own shader for some effects
  • We are missing a lot of minor graphical effects. Fewer shadows and alike, but that’s a hit I think we will just have to accept

Summary

In general it seems that with a relatively small amount of work this might be a valid option for users without working openGL.

It will always be a second class citizen, but it should be do-able to support without hindering progress for the vast majority of users.

What’s interesting is to see how easy it is to support a different scene graph backend, as it is a clear indication of what we will encounter when it comes to Vulcan in a few years time.