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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
