OpenVG support in Qt 4.6

Recently we've been working on writing an OpenVG graphics system for Qt 4.6, and now it is all ready to go!

Qt 4.5 added support for pluggable graphics systems, which allow the window drawing surfaces and their associated paint engines to be redirected to a plugin for handling.  There are graphics systems for OpenGL 1.x and 2.x, and now for OpenVG!

The new graphics system supports OpenVG 1.0 and 1.1, and uses the Khronos EGL API's to access VG contexts and low-level window surfaces.  It directly converts QPaintEngine requests into the equivalent OpenVG requests - the two API's are very similar in functionality, so it was relatively easy to do this.  It has been tested using X11/EGL and S60.  There is also a demonstration plugin that uses ShivaVG, which shows how to use a non-EGL VG implementation.

What's supported?

  • Single-context vs multi-context - the default configuration uses a single VG context and multiple window surfaces.  This improves performance by sharing VG paths, images, and paint objects. But you can switch it to one VG context per window if your engine requires that behaviour.
  • All Qt transformations are supported, both affine and projective.  However projective path transformations need to be done client-side, so they won't perform as well as affine transformations.  Images support both affine and projective path transformations server-side.
  • Pen and brush styles except conical gradients, which don't have a VG equivalent.  Opacity is supported for all drawing operations.
  • All the usual Qt primitives: lines, rectangles, points, polygons, ellipses, etc.  For rectangles and other simple objects, path objects are reused to reduce the overhead of recreating them every time.
  • Clipping uses both masking and scissoring, or just scissoring if your engine doesn't support masking. Scissoring will generally be preferred for simple rectangular clipping.
  • Text drawing is very dependent upon the features in your VG engine. For OpenVG 1.0 it uses the default vector path rendering in Qt, which may not give the best result.  For OpenVG 1.1 systems that support VGfont objects, you have a choice of image-based or path-based glyph uploading.  Image-based glyphs are the default.
  • Pixmaps are represented as VGImage objects (in single-context mode only) and so they can be drawn and transformed very quickly. The pixmap filters from Qt 4.5 (convolution, drop shadow, and colorize) are supported using VG functions.

What's left to do?

  • Testing, testing, testing!  Every VG engine has its subtle quirks so help us narrow them down.
  • Rendering into a QPixmap using VG - at present it drops back to the raster paint engine.
  • Text drawing with image glyphs under OpenVG 1.0.
  • Qt/Embedded support - some experimental screen drivers have been written internally but every vendor's EGL is different, which makes Qt/Embedded difficult to support for both OpenVG and OpenGL/ES.

Where to get it?

You can get the engine from the public Qt repository.  To build it, you'll need to edit your mkspecs to specify the include directories and libraries to link against for EGL and OpenVG.  And then configure Qt with the "-openvg" option.  Once it has built, use "app -graphicssystem OpenVG" to run an app using the graphics system plugin (or "app -graphicssystem shivavg" for the ShivaVG version).


Blog Topics:

Comments

Commenting for this post has ended.

?
Yuriy
0 points
193 months ago

Why OpenVG? He must replace the OpenGL?

?
Rhys Weatherley
0 points
193 months ago

> Why OpenVG? He must replace the OpenGL?

The OpenGL paint engines can still be used and haven't been replaced - OpenVG is just another option for customer hardware that supports it. OpenVG does match a little closer to the QPainter API, so the paint engine was a easier to implement.

?
IvanDM
0 points
193 months ago

Guys, this is a great news. Particularly for Symbian/S60.
Having graphic acceleration based on OpenVG was a bit target and nailing this will make this operating system closer to "modern targets" (anyone said iSomething? ;) ).
Great Jobs guys.

?
boulabiar
0 points
193 months ago

Very very nice news to hear !
This will push OpenVG better, and why not see flash being replaced by something using Qt !

?
Scorp1us
0 points
193 months ago

I don't fully understand how this will affect anything over GL.
How will this affect affine text (from painter paths) over GL? Will it be faster, slower, or the same?
How will this affect general drawing over GL? Will it be faster, slower, or the same?

?
Philippe
0 points
193 months ago

Can this boost graphics on OSX, where performance is so poor compared to Windows?

?
Scorp1us
0 points
193 months ago

I found this post by Zack (a former Troll)

http://zrusin.blogspot.com/...

?
Thiago Macieira
0 points
193 months ago

@Philippe: try running your OSX app with -graphicssystem raster or -graphicssystem opengl already in Qt 4.5 to see if it improves the performance. OSX, like X11, have the "native" paint engine as the default. Windows has no native, so Qt uses the raster engine there.

?
Rhys Weatherley
0 points
193 months ago

> I don't fully understand how this will affect anything over GL.
> How will this affect affine text (from painter paths) over GL? Will it be faster, slower, or the same?
> How will this affect general drawing over GL? Will it be faster, slower, or the same?

The OpenVG paint engine in Qt converts QPainter calls directly into their OpenVG equivalents, so any performance that may be seen compared to OpenGL will be determined by how good the underlying OpenVG implementation is. It is theoretically possible for OpenVG to be better - the OpenGL paint engine in Qt does a lot of work to convert paths (especially curves) into something that GL can render as triangles or line strips. OpenVG on the other hand can pass in the path almost as-is, with the conversion happening in the GPU. But performance variations are certainly likely - OpenGL is a more mature standard so more work has gone into its performance. So on some systems the OpenGL paint engine may still be your best option. We are providing OpenVG as an option, not a replacement, for the OpenGL paint engine. Actual testing is needed on each platform to determine which will be best for you.