Use animation-scheduling API for <marquee> scrolling

Assigned to



7 years ago
7 years ago


(Reporter: mwu, Assigned: mwu)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



7 years ago
Created attachment 476679 [details] [diff] [review]
Use animation scheduling API

This makes pages that use many <marquee>s behave better and use less cpu when the page isn't the active tab. One page (with 50 marquees) that pegs my CPU at ~95% drops to 15-20% with this patch when switching away from that tab. Without this patch, that tab continues to peg the CPU.
Attachment #476679 - Flags: review?(roc)


7 years ago
Attachment #476679 - Flags: review?(roc) → review?(martijn.martijn)
The patch seems to stop marquees entirely in background tabs. Is that what we want to happen. That's not what IE8 is doing.
Created attachment 476683 [details]

This gives an alert when the marquee bounces. That doesn't happen with the patch in a background tab.
Also with the patch, when the file is loaded, then the window is minimized, the alert fires, but then the alert isn't displayed. I guess that might be a bug in the animation-scheduling api.
Created attachment 476684 [details]

With the patch, the marquee in the testcase doesn't run. It does work fine in builds without the patch and in IE8.

Comment 4

7 years ago
One of the goals of the animation scheduling api was being able to throttle animations in background tabs. I think one option was to fire the animation once per second. Don't know if that was implemented but it sounds like it may have been. We can make this code a bit smarter and skip a bunch of steps if the time since the last animation was too long, and fire events as necessary.
We should be firing mozRequestAnimationFrame once per second in background tabs. Is that not happening?


7 years ago
Attachment #476679 - Flags: review?(martijn.martijn)
You need to log in before you can comment on or make changes to this bug.