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

[René J.V. Bertin]

Hi,

A discussion about CPU load recently came up with the author(s) of the newish KBusyIndicatorWidget in the KF5 KWidgetsAddons framework, after I noticed that the test/demo utility runs at 12-13% CPU (according to `top`, on 2 CPUs, a lowly N3150 and a much faster i7). I find that significantly too high, a violation of the principle that measuring tools shouldn't perturb/influence the system they're used on. Ultimately I was told that 1) "they" didn't observe the same load (using a different tool that gives a much lower load estimate for me too; ksysguard5) and that thus 2) I should take up my lamentations with Qt what could be wrong with QVariantAnimation on my system(s) and 3) they're dead against "degrading the user experience" by limiting the animation speed or fluidity.

The widget runs a QPainter rotation of a QIcon from 0 to 360 (degrees, a qfloat) over a 2000ms period; the rotation doesn't appear to be a bottleneck as CPU load remains about the same when I skip the entire rotation & paint step (or an SVG instead of a PNG icon). I don't see any way to influence the animation granularity, so I presume the algorithm fits as many "frames" as possible into the desired duration -- which would explain the constant CPU load. If true that would also make the approach way overkill to indicate a busy-or-not state.

I've isolated the class and its demonstrator, and added a few switches to assess performance (in terms of user experience and CPU load). The only way I found to limit the CPU load is by adding a delay after each frame render. 75ms of "thread sleep" already causes an almost 4x reduction in CPU load with a barely visible effect; with 250ms the animation is choppyish but still perfectly acceptable IMHO - and CPU load < 1%.

github.com/RJVB/kbusygadget

Am I being principled here or are there indeed cheaper ways to obtain a comparable UI effect?

Thanks,
R.

PS: indeterminate (animated) progress bars from styles like Fusion can also cause significant CPU load (see github.com/RJVB/qstyle-demo, the slider page), with similar ramifications re: is this really justified for a UI feedback animation. Another style (QtCurve) uses an in-house QTimer-based animation framework which is roughly 2x cheaper.