[Interest] Utilizing the GPU, how to start?

[Uwe Rathmann]

Hi Sean,

> So what were the results of profiling? CPU usage caused by
> animations/batching, something else? GPU? Bandwidth? Lock contention?

The first time we reported the issue was 2014: https://bugreports.qt.io/
browse/QTBUG-43096. At that time we had to migrate back to Qt 5.1.

When Qt 5.6 came out we made an analysis comparing Qt 5.1 with 5.6. I 
would like to publish it, but as I didn't do it myself ( AFAIK it was 
done by someone having a background in the development of the 5.1 
JavaScript engine ) I can't decide on that. 

But in short: it shows, that Qt 5.6 is much better than 5.3, but still 
behind 5.1. So at some point we will be able to migrate, but of course 
this won't solve problems, that already exist in 5.1.

( The performance of the rendering is significantly better with Qt 5.6, 
but as we never had a problem with rendering. )   

> Any test cases to help others profile it?

Just to give you a silly number: every push button of Controls 1 is made 
of 30 QObjects - every stop of a gradient adds an additional object.

I recommend to do the exercise of counting the number of QObjects below 
the QQuickWindow of an application to everyone. Considering QObject being 
something "heavy" ( QQuickItem even "heavier" ), the numbers are just 
terrifying.

This issue will be part of Andrews presentation ( https://conf.qtcon.org/
en/qtcon/public/events/428 ).

>> The graphic stack behind is irrelevant for the vast majority of the
>> application code and I disagree with Thiago, that it is not possible to
>> implement controls with a similar API as their widget counterparts.

> That's not true. The CPU just isn't capable of doing lots of blending on
> the number of pixels available on typical displays these days.

Sure, but does this affect application code dealing with how to configure 
and lay out controls on a page and what to do, when f.e. a button gets 
pressed ?

Uwe