Issue metadata
Sign in to add a comment
|
High cpu usage of idle renderer - storm of startScrollbarPaintTimer |
||||||||||||||||||||||
Issue descriptionVersion: 56.0.2919.0 OS: OSX El Capitan My canary gets very easily into a state where random processes get very high cpu usage, even when doing nothing. In this case I had only one tab open: http://www2.mouser.com/Passive-Components/Frequency-Control-Timing-Devices/Crystals/_/N-6zu9f See attached trace. The renderer main thread is hammered by timers (TaskQueueManager::DoWork -> startScrollbarPaintTimer). Tese timers doesn't seem to come from the content. If I capture a devtools profile there is no JS activity at all. This seems to happen on random pages. Yesterday it happened to me while opening some PDFs (see Issue 664805 ). CC-ing some scheduler folks, I start wondering whether this is some unintended side-effect of the recent timers throttling.
,
Nov 14 2016
In the meantime adding RB label. Whatever the cause is we shouldn't ship a battery-eating chrome to the public. +charliea: do you know if we have any energy benchmark (or just cpu usage) on mac?
,
Nov 14 2016
Looking at that trace I can see startScrollbarPaintTimer in ./../third_party/WebKit/Source/platform/mac/ScrollAnimatorMac.mm is posting a task that is pegging the CPU. I'm not clear why it's getting posted so often.
,
Nov 14 2016
+bokan who recently touched ScrollAnimatorMac. Can you help triaging?
,
Nov 14 2016
Yah, this is likely my fault. I'll take a look.
,
Nov 14 2016
Running away. :)
,
Nov 14 2016
Aand in turn this seems to be a dupe of Issue 664809 . Glad to see this was caught as a power regression. Did definitely keep my legs warm in these two days :) |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by primiano@chromium.org
, Nov 14 2016