Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
On Wednesday, 16 October 2019 06:33:55 PDT René J.V. Bertin wrote: > What would be the proper way to implement something that behaves like a > QTimer with delay 0 (= fire as soon as the event loop becomes available) > but with an interval (= fire as soon as the event loop becomes available > after at least X msec of pause)? Just use a QTimer with the timeout that you want. The timeout you give is a minimum value. If it gets overrun, it'll simply wake up late. The next time out after that is adjusted: if one timer is late by over 100%, you'll still be woken up only once. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
A thought: What would be the proper way to implement something that behaves like a QTimer with delay 0 (= fire as soon as the event loop becomes available) but with an interval (= fire as soon as the event loop becomes available after at least X msec of pause)? Add a QThread::msleep() call inside the timer callback? Or does that method use QTimer() internally, leading to some kind of interaction leading to an implementation that still keeps updating faster than would be good when something more useful is actually busy? Either way I suppose that this has little to no benefit in case the actual work task runs independently from the eventloop, right? R. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
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(, ::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
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
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. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
On Fri, Oct 04, 2019 at 10:58:44PM +0200, René J. V. Bertin wrote: > Giuseppe D'Angelo via Interest wrote: > > > By default non-QQ2 related animations run every 16ms. Do you have a > > minimal testcase showcasing a suspicious activity of an animation? > > I never said anything about suspicious activity (and the idea that > something could be wrong with Q*Animation on my systems didn't come > from me). But: > > >> github.com/RJVB/kbusygadget > > You'll need a CPU-load measuring tool, of course (I used top, as > mentioned previously, I'm not particularly interested in more advanced > performance analysis). > > If animations run at 60Hz as you say, how do you explain that the app > above runs with essentially the same CPU load on a 1.6Ghz N3150 and a > 2.7Ghz Core i7? The latter CPU should spend significantly more time > waiting to display the next frame. > > I looked for a way to control the animation frequency but couldn't > find one; what did I overlook? I'd take a step back here and check what is really needed for the purpose. Just because one can, in principle, put a vector graphic in svg, than in an icon, and then draw in a transformed painter, steered by a QVariantAnimation, does not really mean that one has to, especially as soon as someone complains about performance. 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. Andre' ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
Giuseppe D'Angelo via Interest wrote: > By default non-QQ2 related animations run every 16ms. Do you have a > minimal testcase showcasing a suspicious activity of an animation? I never said anything about suspicious activity (and the idea that something could be wrong with Q*Animation on my systems didn't come from me). But: >> github.com/RJVB/kbusygadget You'll need a CPU-load measuring tool, of course (I used top, as mentioned previously, I'm not particularly interested in more advanced performance analysis). If animations run at 60Hz as you say, how do you explain that the app above runs with essentially the same CPU load on a 1.6Ghz N3150 and a 2.7Ghz Core i7? The latter CPU should spend significantly more time waiting to display the next frame. I looked for a way to control the animation frequency but couldn't find one; what did I overlook? R. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
Il 04/10/19 16:51, René J.V. Bertin ha scritto: 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? By default non-QQ2 related animations run every 16ms. Do you have a minimal testcase showcasing a suspicious activity of an animation? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] CPU load in busy indicator widget based on Q(Variant)Animation
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. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
