In Qt 5.9 is now possible to render Qt Quick applications with OpenVG when using hardware that supports it. This is made possible by a new scene graph adaptation that uses EGL and OpenVG to render Qt Quick scenes. When using Qt for Device Creation, it means that it now be possible to run with graphics hardware acceleration on some devices where today only software rendering is available.
So what is OpenVG (or if you already know: Seriously… OpenVG?)
OpenVG is an API for hardware accelerated 2D vector graphics. The API exposes the ability to draw and shade paths and images in an accelerated manner. The OpenVG 1.1 standard was developed by the Khronos Group and is implemented by vector GPU vendors. The reason for the tone of sarcasm in my sub-heading and why I am sure there will be more than a few readers eye-rolling is that OpenVG has been around for quite some time. The latest update of the OpenVG 1.1 standard was released in 2008. In addition the Khronos working group for OpenVG has since disbanded likely meaning there will not be any further updates.
This is also not the first time that Qt has supported OpenVG in one way or another. In Qt 4 there was an OpenGL paint engine that enabled QPainter commands to be rendered using the OpenVG API. I do not wish to revive that code, but rather choose to limit usage of the OpenVG API to a smaller subset to accelerate the rendering of Qt Quick applications.
So why OpenVG now?
Qt runs on many embedded devices, but to get the most benefit out of Qt Quick has so far required at least OpenGL 2.0 support. At the same time customers want to use Qt Quick on their low-end embedded devices lacking OpenGL-capable GPUs. So first we introduced the Software adaptation, previously known as the Qt Quick 2D Renderer. See our previous posts here and here. There is however an in-between where hardware has a GPU supporting OpenVG 1.1 but not OpenGL 2.0. OpenVG is a good match for accelerating the rendering of Qt Quick because most features can be enabled, leading to better performance on hardware that has OpenVG-capable GPU.
A few examples of system-on-chips with this configuration are the NXP iMX6 SoloLite, and Vybrid VF5xxR chips which both use the GC355 Vector GPUs enabling OpenVG. The OpenVG working group may no longer be actively working on the standard itself, but SoC vendors are still releasing on hardware that supports OpenVG.
How does it perform?
The expected behavior for the OpenVG adaptation is that it fills the space between OpenGL and Software rendering. With hardware that supports both OpenGL and OpenVG, expect the OpenGL renderer to outperform OpenVG as OpenGL gives more opportunities for optimisation. If you test the OpenVG adaptation on a Raspberry Pi you will see that default OpenGL renderer will do significantly more before dropping below 60 FPS.
How can I make use of the OpenVG adaptation?
To use the OpenVG backend you will need to build Qt with support for it. In Qt 5.9 we have re-added a test for OpenVG support which will enable the feature in Qt Quick. Once you have a suitable build of Qt deployed to your target device you will need to run your application with a platform plugin that supports EGL (EGLFS or MinimalEGL). Then if you set the environment variable QT_QUICK_BACKEND=openvg your Qt Quick applications will create OpenVG capable EGL surfaces, and render using OpenVG commands. For more information, see the scenegraph adaptation section at the snapshot documentation site.
Like the Software adaptation, the OpenVG adaptation comes with some limitations due to the lack of 3D and Shader Effects. It is not possible to use QML components that depend on OpenGL or Shader Effects directly. That means that Qt Quick modules like Particles and Graphical Effects are not available. If your application works with the Software adaption, it will work better with the OpenVG backend with hardware capable of using it.
The EGLFS platform plugin also introduces some limitations. When using EGLFS platform with Qt for Device Creation you may have become accustom to having a mouse cursor and support for multiple child windows. Despite the platform plugins name (EGL Fullscreen) it is a bit naughty and does use OpenGL for a few things. Specifically composing multiple windows and the mouse cursor. If you use EGLFS on a platform without OpenGL though, these features are not available. In a shipping device this usually isn’t an issue. It can be annoying if you don’t expect it during the development phase. Funny enough we had a very similar limitation with the OpenVG paint engine in Qt 4 with QWS.
In the embedded space there is a need to make use of any available resources. This adaptation is just one more way that Qt is helping fill that need. I hope that this adaptation will make some of your device creation efforts easier so that you can spend more time making cool products with Qt. Thanks for reading and keep on hacking.