[Interest] CPU load in busy indicator widget based on Q(Variant)Animation

René J.V. Bertin rjvbertin at gmail.com
Sat Oct 5 09:29:17 CEST 2019


On Friday October 04 2019 23:56:13 André Pönitz wrote:

Hi,

>I'd take a step back here and check what is really needed for the
>purpose.

That was my actual purpose here... Thing is, in order to indicate "we're busy", you can toggle a state (green becomes red), play a waiting music or display a full simulation of the thermodynamic processes in a race engine. It all depends on how you define "needed for the purpose" ;)

>by a QVariantAnimation, does not really mean that one has to,
>especially as soon as someone complains about performance.

To be honest, I haven't yet noticed a performance implication but that's also because the widget is too new for me and I haven't looked for it. After all we're not talking about 50% CPU waste; 10-12% probably won't be apparent immediately. It's more likely that you'll start noticing a less nice "user experience" in the widget itself when the system begins to be swamped...

But about using a QAbstractAnimation derivative in UI feedback: it is also used in animated (indeterminate) progressbars in many widget styles

>I haven't checked, but I am ready to bet that "finger painting"
>the in the paintEvent(), triggered by a timer calling update will
>take significantly less resources.

That would be an easy fix: the rotation already happens in the paintEvent() which apparently is far easier in there than in other parts of the code (no need to compensate scaling).
I am going to check if you're right, you probably are; indeterminate progressbars are 2x less resource-intensive in my theming of the QtCurve style as they are in Fusion, and that must be due to the use of what you call finger painting.

But Q*Animation in basic form shouldn't need to be so much more intensive, right? You'd be doing the same work in a finger-painting approach if you want the same animation parameters (here, rotate from 0 to 360 in 2s with 16ms intervals). Can there really be so much overhead in calculating the animation parameter (via QVariant)?

R.


More information about the Interest mailing list