[Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

Uwe Rathmann Uwe.Rathmann at tigertal.de
Thu Aug 30 09:44:21 CEST 2018


On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote:

> So, there are no way to improve an acceleration and to minimize the CPU
> loading?

It depends on the requirements of your application, but when it comes to 
oscilloscope alike widgets your best choice is Qt4/X11.

The X11 paint engine is hardware accelerated, it even allows painting 
outside of paint events - what is important for incremental painting.

( The fact, that Qt 4.8 prefers using raster with the argument of 
performance it is totally nonsense, when it comes to any sort of vector 
graphics. )

Furthermore the X11 paint engine simply has a better quality. The sort of 
bugs coming and going with the various Qt versions is a nightmare for any 
sort of graphics framework. Actually my job for today is to find a work 
around for this one: https://bugreports.qt.io/browse/QTBUG-70101

--

If you need to go with Qt5 I would recommend to use a platform that 
allows for using QOpenGlWidget - X11 again is IMHO not a bad choice. 
Actually one of our terminals is a iMX6, where we do this ( because we 
needed VNC support ).

Next I recommend Qwt from SVN trunk, where you can simply assign a 
QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the 
OpenGL paint engine is not as good as X11 or Raster, but for a 
oscilloscope things usually do not need to be pixel perfect.

--

Finally you should not ignore algorithmic options to reduce what has to 
be painted. How to optimize the rendering process is often quite 
individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt 
6.2 ) has a significant effect in oscilloscope alike applications.

In fact I have been contacted quite often with oscilloscope applications 
struggling with performance issues and often it could be solved on a 
algorithmic level.

As an inspiration you could also try to run the oscilloscope demo of Qwt 
on your board. You will notice, that it runs with almost no CPU usage 
because it mostly paints incrementally. Of course this only works because 
the design of the user interface is made for this, but maybe you can do 
something similar.

Uwe





More information about the Development mailing list