Andy Nichols (nezticle)

Introducing the Qt Quick 2D Renderer

Published Thursday January 22nd, 2015
11 Comments on Introducing the Qt Quick 2D Renderer
Posted in Embedded, OpenGL, Qt Quick 2

When Qt Quick 2 was introduced with the release of Qt 5.0, it came with a minimum requirement of either OpenGL 2.0 or OpenGL ES 2.0.  For desktop and mobile platforms this is usually not an issue, and when it is for example on Windows, it is now fairly easy to use an OpenGL software rasteriser as a fallback.  If however your target is an embedded device without a GPU capable of OpenGL ES 2.0, then software rasterisation of OpenGL is an unwise option.  It is typical that the embedded devices without a GPU have less CPU resources available as well, so the overhead introduced by the software rasterisation of OpenGL leads to unacceptable performance for even the most simple content.  Also many of the performance optimisations gained by using OpenGL for rendering Qt Quick 2 scenes are negated by software rasterisation.

So as a solution to our Professional and Enterprise customers we are now providing an alternative scene graph renderer called the Qt Quick 2D Renderer.  The Qt Quick 2D Renderer works by rendering the Qt Quick scene graph using Qt’s raster paint engine instead of using OpenGL.   Using the Qt Quick 2D Renderer is as simple as building the module and setting an environment variable:

export QMLSCENE_DEVICE=softwarecontext

Now instead of loading the default render which uses OpenGL, Qt Quick will load our renderer plugin instead.  This plugin makes it possible to run Qt Quick 2 applications with platform plugins without OpenGL capability, like LinuxFB.

But wait! Doesn’t the QtQuick module itself depend on OpenGL?

Unfortunately, the Qt Quick module cannot be built without Qt itself being configured with OpenGL support.  So even though most calls to OpenGL inside of Qt Quick module are now moved to the renderer, Qt Quick still has APIs that cannot be changed for the Qt 5 release series and depend on OpenGL.  Fortunately as long as you do not use those APIs, no OpenGL functions will be called.

So along with the Qt Quick 2D Renderer module we provide a set of dummy libraries and headers that will allow you to build Qt with OpenGL support, enabling you to build and use the QtQuick module.  However if you accidentally call any OpenGL functions, do not be surprised when your application crashes.

Limitations

So there are some downsides to not using OpenGL.  First and maybe most obvious is that any scene graph nodes that require the use of OpenGL are ignored.  Since the Qt Quick 2D Renderer is not actually rasterising the OpenGL content, but rather providing an alternative set of render commands to provide the same result, it is not possible to use any OpenGL.  Existing functionality in Qt Quick 2 that requires OpenGL to be present like ShaderEffects or Particles can not be rendered.  So in many cases your Qt Quick UI containing these elements will still run, but the portions of your UI depending on these Items will not be displayed.

The second limitation you can expect is a serious performance penalty.  When rendering with OpenGL and a GPU, you will get painting operations like translations basically for free. Without OpenGL however operations like rotating and scaling an item become expensive and should be avoided whenever possible.  We also cannot easily do neat tricks to determine what not to paint.  We have to fall back to the painter’s algorithm and paint everything visible in the scene from back to front.

Another thing to keep in mind is that partial updates of the UI are not supported.  That means that if something in the scene needs to be redrawn, everything in your Qt Quick window will be redrawn.  This is not likely to be changed, and is due to the primary use case of Qt Quick 2 being an OpenGL renderer. 

Hardware Acceleration

Even though the lack of OpenGL translates to some pretty big compromises regarding performance with Qt Quick 2, all hope is not lost.  Many devices still have hardware available to accelerate 2D graphics.  This hardware is typically capable of accelerating certain types of painting operations like copying pixmaps and filling rectangles.  The Qt Quick 2D Renderer is optimised to take full advantage of any 2D hardware acceleration that may be provided by a platform plugin.

For embedded Linux the DirectFB platform plugin can enable Qt to take advantage of 2D graphics acceleration hardware if available.  If you then use the Qt Quick 2D Renderer with the DirectFB plugin, the drawing of QQuickItems like Rectangle, Image, and BorderImage will be accelerated in many cases.  2D graphics hardware does have limitations to what transformations can be accelerated though, so keep in mind that if you set the Rotation on an Item you will not be able to take advantage of hardware acceleration.

Not Just Embedded

It is worth mentioning that while the Qt Quick 2D Renderer was developed with the “embedded devices without OpenGL” use case in mind, its use is not limited to embedded.  It is possible to test out the Qt Quick 2D Renderer on non-embedded platforms by using the same environment variable.  Keep in mind though that with the 5.4.0 release there are some rendering issues with screens that have a device pixel ratio greater than 1.0.  This should be resolved in the upcoming 5.4.1 release.

Who should use this?

For an embedded device project if the requirement is a fluid UI with 60 FPS animations like those seen in the average smartphone, then you absolutely need hardware that supports OpenGL ES 2.0.  If however you have existing hardware without a GPU capable of OpenGL ES 2.0 or just lesser expectations on lower cost hardware, then the Qt Quick 2D Renderer is the way to go when using Qt Quick 2.

Qt Quick 2D Renderer also provides the opportunity to share more code between the targets in your device portfolio.  For example if you are deploying to multiple devices that may or may not have OpenGL support, you can use the same Qt Quick 2 UI on all devices, even on the ones where previously you would either need to have a separate UI using QtWidgets or the legacy QtQuick1 module.

For desktop there are a few cases where it may make sense to use the Qt Quick 2D Renderer.  On Windows it can be used as an alternative to falling back to ANGLE or Mesa3D in the situation where neither OpenGL 2.0 nor Direct3D 9 or 11 are available.  It also makes it possible to run Qt Quick 2 applications via remote desktop solutions like VNC or X11 forwarding where normally the OpenGL support is insufficient.

Looking Forward

The Qt 5.4.0 release is just the start for the Qt Quick 2D Renderer.  Work is ongoing to improve the performance and quality to provide the maximum benefit to device creators writing Qt Quick 2 UIs for embedded devices without OpenGL.  One of the things that is being worked on now is enabling the use of QtWebEngine with the Qt Quick 2D Renderer which currently is unavailable because of a hard dependency on OpenGL.  Here is a preview of QtWebEngine running on a Colibri VF61 module from Toradex:

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Embedded, OpenGL, Qt Quick 2

11 comments

Guy says:

Which has best performance? Qt Quick 2 +Qt Quick 2D Renderer or just Qt Quick 1? Both on Linux Embedded without OpenGL?

andynichols andynichols says:

In many cases the performance of both Qt Quick 2 + Qt Quick Renderer and Qt Quick 1 end up being very similar. For both we end up calling similar commands via QPainter to render the scene, however there are cases where Qt Quick 1 will be faster due to its partial updates. The bigger issue with using Qt Quick 1 though is that it is in the process of being deprecated and is currently unmaintained.

hwti says:

With OpenGL partial updates are possible using GLX_EXT_buffer_age or EGL_EXT_buffer_age, but I don’t know if it would be easy or not to implement this in QtQuick2.

andynichols andynichols says:

When we render with OpenGL there is not as much to gained by doing partial updates. The current architecture of scene graph is ideal for the OpenGL case, but it assumes we regenerate the content of the framebuffer every frame.

Laszlo Agocs Laszlo Agocs says:

Having a way to do partial swaps is one thing, the real issue is to calculate and track dirty areas which can quickly get complicated and costly.

chezgi says:

is it only for commercial versions? or we can use it in community version of Qt.
thanks

andynichols andynichols says:

The Qt Quick 2D Renderer is only available with the Professional and Enterprise versions of Qt.

Tim Day says:

One thing it would be nice to see emerge from an alternative-to-OpenGL qtquick2 software renderer backend is the ability to produce PDFs; see http://stackoverflow.com/q/20825233

nezticle nezticle says:

It should not be too hard to render a QtQuick 2 scene as a PDF with the current approach to the Qt Quick 2D renderer. Since we use the QPainter API to render the scene to a QPixmap via the Raster paint engine, we could just as easily use a QPrinter instead. We would just need to add the infrastructure to switch the output target, but definitely something worth looking in to.

André Somers says:

That would be very cool indeed. I have written a report system that uses QtQuick as its template language. That works very nicely, but I was sticking with Quick1 mainly because of the painter issue. KDAB also recently blogged on the workaround they wrote to be able to generate PDF from presentations made in Quick 2 (basically by manually rendering images and texts).

This approach seems better. Please consider putting this in the mainline Qt though, as it is applicable to so many more applications than just embedded systems without GL support.

Nitin says:

Is there on going work to accelerate video decode using qt-quick2/qtmultimedia?

Commenting closed.

Get started today with Qt Download now