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

[Uwe Rathmann]

On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote:

>> From my experience with the QSkinny project I'm tempted to say that it
>> would even be possible to implement the Qt/Widgets API on top of
>> Qt/Quick core.
> 
> So long as you ditch the paint event for most of the classes, leaving
> the QQuickPaintedItem (or whatever it's called) only for the cases where
> it's truly needed.

When implementing widgets ( inside of Qt or 3rd party widgets like in Qwt 
) it is mostly a matter of handling resize and paint events.

The corresponding calls for Qt/Quick are QQuickItem::geometryChanged and 
QQuickItem::updatePaintNode().

So when trying to migrate widgets into being QQuickItems you would have 
to send QResizeEvents inside of geometryChanged and QPaintEvents inside 
of updatePaintNode.

All of these "widgets" could have an FBO ( or QPixmap ) inside and 
creating a QPainter on a them would result in drawing to this one. Then 
it would be possible to create a scene graph node from it.

Of course I'm heavily oversimplifying, but this way you would at least 
get something running in a reasonable amount of time - even if this would 
downgrade the scene graph into being a texture cache.

But it would be a starting point for migrating the implementation of 
updatePaintNode widget by widget.

--

But does it make any sense to spend time on this:

In the context of Qt 5.0, where the strategy was to replace Widgets by 
Quick Controls 1 - probably not.

But QC1 has become a failed technology and QC2 is not targeting the 
desktop anymore. So all what Qt has to offer today for the desktop is 
good old Widgets - running on a graphic stack, that is not competitive 
anymore.

So in the retrospective IMHO the wrong decision had been made.
And for the future - no idea, is there already a strategy how to satisfy 
desktop users with Qt 6 ?

Uwe