1246045 - Throttle animations in out-of-view iframes

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[panoworks]

-- steps to reproduce --
1. Make sure your power plan turns off the screen after a certain time (1 minute for expediency, say)
2. Visit a site with CSS animation, e.g. https://www.mozilla.org/en-US/firefox/42.0/whatsnew/?oldversion=38.0.1 ( the page causing me to notice this ) or https://css-tricks.com/almanac/properties/a/animation/
3. Leave that tab open.  You can minimize FireFox - doesn't matter.
3.5 Run PerfMon, add a monitor for Process > Processor % for all processes
4. Wait the allotted time
5. Notice CPU fan spin-up.  Move mouse to figure out what's going on, check task manager, notice nothing seems to be using the CPU particularly much, remain baffled.
5.5 Check PerfMon and notice firefox.exe / dwm.exe was the culprit that quickly disappeared as soon as you moved the mouse.

-- observed behavior and circumstances --
firefox.exe / dwm.exe CPU use goes up well beyond normal use once the power plan turns off the screen.
Minimizing/windowing/maximizing the browser does not prevent this issue.
Safe mode does not prevent this issue.
A clean profile does not prevent this issue.

Switching to a tab that doesn't have CSS animations prevents this issue.
Disabling the screen being turned off (using dimming and/or a screensaver only) prevents this issue.

-- expected behavior --
dwm.exe cpu use should not go above usage when the screen is left on.

-- additional information --
Could not reproduce this issue with Chrome or Internet Explorer.

I attempted to create a Gecko Profiler performance report, however it got stuck on "retrieving profile" (which appears to be another bug, but if nobody can reproduce this issue and there's some way to get it going, I'd be happy to give it another shot).

There are some other reports on the internet about similar bugs involving other software.  For example, the "setpoint.exe" software included with some Logitech software exhibits/exhibited the same issue.  A purported debug trace suggested that one piece of software, some version of Outlook, was attempting to draw to the screen, got an error result, and just kept trying again and again in quick succession, effectively pegging several cores.  A long discussion with information and misinformation is available at https://social.technet.microsoft.com/Forums/windows/en-US/6884366d-6759-4ab9-89c5-fd6af8008b28/dwmexe-starts-consuming-lots-of-cpu-when-machine-is-idle?forum=w8itproperf

Comment 1

[YF (Yang)]

WFM on Fx45b2 & Nightly 47.0a1 in Win10.

Comment 2

[Jan Sonntag]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
BuildID: 20160205030204

Unfortunately, I failed to reproduce this issue under Win 7 64-bit.

Comment 3

[panoworks]

Thank you YF (Yang) and Jan Sonntag.  I can still reproduce the issue here, so I thought I'd at least give the Gecko Profiler another shot - eventually managed to at least get some data being displayed.

Other than identifying the 10 second span in which I let the screen be turned off, I admit I'm not sure what to do with this, given that sharing doesn't seem to work (pressing "upload" in the privacy notice dialog only closes the dialog) and saving locally does much the same (i.e. nothing, apparently).

I know a screenshot isn't going to help much, but maybe there's some things I can click on or do different to help figure this out further.  http://i.imgur.com/Z99Rr5e.png

Comment 4

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Hi Panoworks,

I have tested your issue on latest Nightly (47.0a1) and could not reproduce it on Windows 7 64x, but I managed to reproduce it on Windows 8 x64. I followed the provided steps and when the display is turned off, firefox.exe / dwm.exe processes spike the CPU usage up well beyond normal (60-80%).

Firefox: 47.0a1, Build ID  20160207030402
User Agent  Mozilla/5.0 (Windows NT 6.2; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

Considering this, I will mark this issue as New and assign a component to it. 


Thanks,
Cosmin.

Comment 5

[u279076]

Cosmin, please provide the following:
* copy of about:support for the system where this reproduces
* detailed steps to reproduce the issue
* a regression window, if this is indeed a regression

Thanks

Comment 6

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: windows 8 about support.txt

Hi Anthony,

Steps to reproduce:

0. Make sure your power plan turns off the screen after a certain time (lets say 1 minute)
1. Visit a site which contains CSS animation, e.g. https://www.mozilla.org/en-US/firefox/42.0/whatsnew/?oldversion=38.0.1) or (https://css-tricks.com/almanac/properties/a/animation/)
2. Leave that tab open. 
3. Run Performance Monitor, click on Monitoring Tools -> Performance Monitor and click on the green plus sign to add a monitor for Process -> %Processor Time, add from "Instances of selected object": firefox.exe and dwm.exe and click add and then click OK.
4. Focus the tab with CSS animation page.
5. Wait the allotted time to turns off the screen.
6. After ~1 minute, move your mouse and check the Performance Monitor.
7. Notice that firefox.exe / dwm.exe processes spike the CPU usage up well beyond normal (60-80%).

After the regression window I have found the version where the change occurred. This is the pushlog link (https://goo.gl/yU1iO3). I think this issue occurred on Windows 8 after the bug 1145912 was fixed. Cameron what is your opinion, do you think this is possible?

I have attached a screenshot with actual result and a file with about:support from the system where this reproduces.

Thanks,
Cosmin.

Comment 7

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: Windows 8 screenshot.jpg

Comment 8

[panoworks]

(In reply to Cosmin Muntean [:CosminMCG] from comment #4)
Hi Cosmin,

Thank you for confirming - was starting to think it was just my machine.

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #5)
Anthony, if you'd like an about:support from my machine as well, I should be able to provide one.

Comment 9

[u279076]

(In reply to Cosmin Muntean [:CosminMCG] from comment #6)
> Created attachment 8718369 [details]
> windows 8 about support.txt

I'm not sure if this is correct but your about:support shows a driver date that is 10 years old. Can you double check that you're running the latest drivers available for your system?

> After the regression window I have found the version where the change
> occurred. This is the pushlog link (https://goo.gl/yU1iO3). I think this
> issue occurred on Windows 8 after the bug 1145912 was fixed. Cameron what is
> your opinion, do you think this is possible?

I don't think that's possible since the only code that was changed was in a test. This would not affect the shipped product in any way. Did you use mozregression to get that window? If so, please try to re-regress it manually.

Comment 10

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: about support.txt

Hi,

I have tested again this issue on a different machine and downloaded AMD Catalyst Install Manager. It automatically detected and installed the the latest driver. Also, I've tried to update the driver from Generic PnP Monitor "Properties", but it showed that the last version of the driver was installed. Even so, I was still able to reproduce this issue.

I have performed a manual regression and the last good version I found is Nightly 40.0a1 (Build ID: 20150401030204), and first bad version is Nightly 40.0a1 ( Build ID: 20150402115826.). The pushlog link is http://goo.gl/wlEbQQ.

Thanks,
Cosmin.

Comment 11

[u279076]

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b88606f8fe7&tochange=35046df9df1f

Seems like bug 847287 is a likely culprit. David, can you take a look at this?

Comment 12

[Cameron McCormack (:heycam)]

Anthony, do you know if this bug is still relevant?

Comment 13

[u279076]

(In reply to Cameron McCormack (:heycam) from comment #12)
> Anthony, do you know if this bug is still relevant?

I cannot reproduce it on my Windows 8 laptop with Firefox 59.0.2 but I can't reproduce it with the regressed build above either. Probably need Cosmin or panoworks to check if this still reproduces.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

I don't see any animations in https://www.mozilla.org/en-US/firefox/42.0/whatsnew/?oldversion=38.0.1, but I see animations inside iframes in https://css-tricks.com/almanac/properties/a/animation/.  But most of iframes are out-of-view, so the animations can be optimized once we drop nsLayoutUtils::SCROLLABLE_SAME_DOC in IsFrameScrolledOutOfView[1].

That's said there is(are?) another annoying animation that is border-radius animation which doesn't specify 100% keyframe value.  We have been doing special handling for such missing keyframes but only for opacity and transform.  Actually border-radius produces only RepaintFrame change hint so we can throttle it.  We might need a generic way to optimize missing keyframes.  IIRC, in the past we had MaxDifference (or something like that) for each style struct, we might need something like that for each CSS properties.

Anyway, other than the border-radius animation, we can optimize other animations.  So whatever regressed this in the past, we can improve this.

[1] https://hg.mozilla.org/mozilla-central/file/1c235a552c32/layout/generic/nsFrame.cpp#l10968

Comment 15

[panoworks]

(In reply to Anthony Hughes (:ashughes) [QA] from comment #13)
> I cannot reproduce it on my Windows 8 laptop with Firefox 59.0.2 but I can't
> reproduce it with the regressed build above either. Probably need Cosmin or
> panoworks to check if this still reproduces.

Apologies for the delay, did not notice a reply until Marco's edit a few hours back.

I can't repro, but its been 2 years - the laptop in question had 8.1 installed on it, probably some driver updates, and FireFox's entire process handling changed in 57.  I'd be happy to test with an older version and see if it still happens with that (eliminating changes to the laptop), as well as trying to eliminate much of FireFox's process handling changes (tried googling - getting a lot of conflicting results), BUT I'd also be just fine with closing this bug and re-opening it if somebody else comes across the behavior.

For what it's worth, the behavior I'm seeing now is that processor usage *drops* significantly once the screen is turned off.  I'd call that an improvement.

Comment 16

[panoworks]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #14)
> I don't see any animations in
> https://www.mozilla.org/en-US/firefox/42.0/whatsnew/?oldversion=38.0.1

Yes, it seems the website was reworked in the interim as well.  Archive still has a copy;
https://web.archive.org/web/20151104214256/https://www.mozilla.org/en-US/firefox/42.0/whatsnew/

The robots' blinking was the animation.

Looks like you noticed room for improvement aside from the original report, so while I can't repro the original issue, I'm glad some good can indirectly come from it years down the line :)

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Thanks for the update.

I think the css-tricks.com case is pretty common in the wild and easy to be fixed as far as I can tell.  It's worth doing.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cdede35ed124c96f4aa30f6e9e2d15d070fdf12c

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1246045 - Throttle animations in out-of-view iframe.

The test case added here fails without this fix.

Review commit: https://reviewboard.mozilla.org/r/253858/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/253858/

Comment 19

[Brian Birtles (:birtles)]

Comment on attachment 8988627 [details]
Bug 1246045 - Throttle animations in out-of-view iframe.

https://reviewboard.mozilla.org/r/253858/#review260568

This patch could use a more descriptive commit message.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 8988627 [details]
Bug 1246045 - Throttle animations in out-of-view iframe.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253858/diff/1-2/

Comment 21

[Brian Birtles (:birtles)]

I guess "the css-tricks.com case" refers to sites that have embedded codepens and the like?

Comment 22

[Brian Birtles (:birtles)]

Comment on attachment 8988627 [details]
Bug 1246045 - Throttle animations in out-of-view iframe.

https://reviewboard.mozilla.org/r/253858/#review260608

Comment 23

[Hiroyuki Ikezoe (:hiro)]

(In reply to Brian Birtles (:birtles, traveling 29 June - 6 July) from comment #21)
> I guess "the css-tricks.com case" refers to sites that have embedded
> codepens and the like?

Yes, exactly.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c4cc89153238
Throttle animations in out-of-view iframe. r=birtles

Comment 25

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/c4cc89153238

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Seems like this can probably ride the trains, but feel free to nominate for Beta if you feel strongly otherwise.