Image Display Performance

Programming Questions C++ API
1

At first glance displaying an image on screen seems like simple task. However, it can become quite tricky if your requirements deviate from the main stream in essential points. Unfortunately, this is the case for quite some machine vision applications.

Therefore, CVB++ offers a ImageView class based on Qt’s QGraphicsView with a lot parameters to configure for optimal results.
One that is especially powerful but not trivial to chose correctly is the render engine.

There are three options.

  • Raster
  • OpenGL2
  • OpenGL3

The raster engine offers reasonable performance and should work independently of your target systems graphics HW. OpenGL3 requires OpenGL3 ES and depending on your implementation might be the best choice. Finally OpenGL2 is aligned with Qt’s minimal OpenGL requirements and can offers a trade of between speed and driver requirements.

So, how to make right choice?

CVB++ brings a source example (QtDisplayAdvanced) that allows you to measure the different render engines on your system.

Here are some results just recorded on my system:

image
image.png927×265 38.4 KB

2

Thanks for providing this - since we plan to use CVB + C++ + QT this is very helpful.

However, when running the sample code the performance using the raster rendering is much (5x) better than when using OpenGL (on Win7+Intel Desktop and on Win10 + 1070 + latest drivers).

What could be the reason for this?

3

Hi @Jakob,

it is unfortunately hard to tell what wrong with you OpenGL setup, as I see various possible reasons and things to check.

  • make sure V-Sync is disabled, this could have heavy impact on the performance test.
  • test your current vendor and render strings returned from OpenGLImageRenderer::RendererName/VendorName. There might be an unfortunate fall back at some point.
  • Check if your Qt version was complied with -opengl dynamic? As far as I know the stock version is!
  • Check if setting environment variable QT_OPENGL=angle changes your performance. Note this will force OpenGL rendering through Angle which is implemented on top of DircectX.

For further in depth information I recommend:

Finally I’d like to mention that for very small image the raster engine will be faster, however my feeling is that this would be only a little difference.

4

Thanks for the answer and for the helpful link!

vSync seems to do the trick, here some figures:

Image 640x400, View 616x458

Intel HD 530, slower machine, Win7
(Software=Gallium 0.4 on llvmpipe)

Raster: 300 fps
QT_OPENGL=“software”, OpenGL 3: 460 fps
QT_OPENGL=“software”, OpenGL 2: 330 fps
QT_OPENGL=“angle”, OpenGL 2: 120 fps
QT_OPENGL=“desktop”, OpenGL 2: 60 fps
QT_OPENGL not set, OpenGL 2: 60 fps

nVidia GTX 1070, Win10, faster machine i7-6700@3.4 GHz, Win10
(Software=Gallium 0.4 on llvmpipe)

Raster: 1300 fps
QT_OPENGL=“software”, OpenGL 3: 1050 fps
QT_OPENGL=“software”, OpenGL 2: 730 fps
QT_OPENGL=“angle”, OpenGL 2: 120 fps
QT_OPENGL=“desktop”, OpenGL 2: 120 fps
QT_OPENGL not set, OpenGL 2: 120 fps
QT_OPENGL not set, OpenGL 2: 1500 fps VERTICAL SYNC OFF
QT_OPENGL not set, OpenGL 3: 2140 fps VERTICAL SYNC OFF

As you can see, on the fast fast machine (which is the actual target) the vertical sync changes the results by more than a factor of 10!
On the slower machine I cannot turn off vertical sync (the drivers do not seem to allow this). But this is more a nuisance than a real problem for me.

Using qtdiag I could confirm that the driver is selected as could be expected from the QT_OPENGL value (i.e. the nVidia Card is selected when I use “desktop” or do not specifiy anything).

Setting QSG_INFO=1 did not do anything for me, though - I got no messages, neither on the console nor on DebugView (I am not using QT Creator). Probably I am doing something wrong; but this is not essential, since qtdiag already provides a lot of Information.

1 Like