D7640: QtCurve: reduce progressbar timer overhead
René J.V. Bertin
noreply at phabricator.kde.org
Fri Sep 1 11:43:49 UTC 2017
rjvbb created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
REVISION SUMMARY
Debugging an unrelated timer issue with GammaRay I noticed QtCurve can have multiple progressbar timers active in more complex applications like KDevelop even when progressbar aren't being animated (or are in fact not being shown/active). Progressbar timers run at 20Hz, which seems a bit fast for idling.
This patch introduces a rather basic improvement. The progressbar timer is started at an idling frequency of 2Hz unless it's being started for a progressbar which requires animation. It will then be set to the working frequency in the timerEvent callback, if and only if there are progressbars to be animated.
TEST PLAN
Works as expected. There's a small hickup when a progressbar is switched to animated (or "busy") mode, but one that ought to be hardly noticeable in real life.
The current version of the patch has hysteresis: timers are never switched back to idling frequency. I'm looking how much more complex the code becomes when they're turned back down as soon as there are no more animated progressbars.
NB: I'm not entirely certain why multiple timers would be active, it seems there ought only be a single one per process.
REPOSITORY
R626 QtCurve
REVISION DETAIL
https://phabricator.kde.org/D7640
AFFECTED FILES
qt4/style/qtcurve.cpp
qt4/style/qtcurve.h
qt5/style/qtcurve.h
qt5/style/qtcurve_api.cpp
qt5/style/qtcurve_p.h
To: rjvbb, yuyichao, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170901/4ad6e777/attachment-0001.html>
More information about the Plasma-devel
mailing list