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