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

[René J.V. Bertin]

On Saturday October 05 2019 09:29:17 René J.V. Bertin wrote:

>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)?

Confirmed, with

```
        aniTimer.setInterval(1000/frequency);
        QObject::connect(&aniTimer, &QTimer::timeout,
                q, [=]() {
            q->update(); // repaint new rotation
            // use the actual dt obtained from a QElapsedTime instead of the programmed dt
            // the conversion from ms to s is implicit through the unit of durationMs;
            auto elapsed = aniTime.restart();
            rotation += elapsed * 360.0 / durationMs;
            if (rotation > 360) {
                rotation -= 360;
            }
        });
```

I observe exactly the same CPU loads, even with the default QCoarseTimer. Am I doing something wrong here?
Curiously I do see a bit more of an effect of running a bogus animation here but even here loads remain high; 10% for just triggering a signal that calls a lambda 60 times per second? What kind of overhead does QWidget::update() incur, because when I shunt `q->update()` in the snippet above the load drops drastically.

R.