Open Bug 1469594 Opened 6 years ago Updated 2 years ago

Firefox Mac: animations should throttle when there is no frame to frame change, like Chrome and Safari do

Categories

(Core :: Graphics, defect, P5)

59 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mark.paxman99, Unassigned)

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180619102337

Steps to reproduce:

Firefox Mac

bug 1265824 comment 107 has a CSS animation test case, five dots sliding across the screen.

For part of the animation cycle the screen is blank. Perhaps 1 second out of the 3 second animation.

Safari and Chrome seem to reduce the refresh FPS (to zero?) during that time. Firefox does not. It runs at 60 fps throughout the animation cyle.

You can see in Quartz Debug FPS meter, Chrome & Safari present a wiggly line which peaks at 60 fps and reduces during the blank period of the animation cycle. FF presents a flat line at 60 fps even when the screen is blank. I think Quartz Debug has a smoothing filter so I don't think it shows the full throttling effect.

I've attached screen grabs of Firefox (pegged at 60 fps) and Chrome (wiggly, averaging ~40 fps).

I can see the same effect on bug 1449267 attachment 1 [details] [diff] [review], Firefox always refreshes at 60 fps during the throbber cycle, Chrome averages about 30 fps with a wiggly line. I guess because the throbber is static for part of its cycle.

Throttling the display refresh during static periods would save battery, partly from reducing CPU workload and, on Macs at high scaled resolution, by reducing the GPU power consumed by the MacOS compositor.

see also bug 1422090 and bug 1429522.
http://la-grange.net/2018/05/30/test/loading.svg

This is the site in question.  There are five animations from 'transform: none' to 'transform: translateX(864px)', and one animation on the parent element of the five animations which is from 'translateX(-40px)' to 'translateX(30px)'.  So I guess chrome throttled the animations if the elements are out of screen.  Anyway this is an issue on graphics area since all the animations run on the compositor.
Component: Untriaged → Graphics
Product: Firefox → Core
(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
> http://la-grange.net/2018/05/30/test/loading.svg
> 
> This is the site in question.  There are five animations from 'transform:
> none' to 'transform: translateX(864px)', and one animation on the parent
> element of the five animations which is from 'translateX(-40px)' to
> 'translateX(30px)'.  So I guess chrome throttled the animations if the
> elements are out of screen. 

To be clear, the 'out of screen' means here is that the transform value is between 'translateX(-40px)' and 'translateX(nearly 0)'.
Another nice example is bug 1449267 attachment 1 [details] [diff] [review]

Chrome throttles when the image slideshow (Mugabe) is static between fades. Firefox does not & Safari does not.

So Chrome runs at an average of maybe 15 fps vs 60 fps for Firefox (and Safari). 

A power saving? May not be worth chasing until you see what Core Animation does for your power consumption.
(In reply to Mark from comment #5)
> Another nice example is bug 1449267 attachment 1 [details] [diff] [review]

The example is not suitable for this bug.  The keyframes for the animation in question is;

0% {
    opacity: 1;
}
10% {
    opacity: .25;
}
40% {
    opacity: 1;
}
100% {
    opacity: 1;
}

We can optimize this kind of keyframes with pre-computing change-hintish information.  I did actually leave such comment somewhere, but couldn't find it now.
I guess I filed a meta-bug in the general case:- Firefox should throttle when there is no frame to frame change.

And now we have two specific examples of the bug:- 

* comment zero

* comment 5

I don't understand CSS animations so I can't see the cause of the problem (the CSS animation properties). I can only see the effect - failure to throttle.

would you like me to file comment 5 as a separate bug?
No, I found it. bug 1461239.
Priority: -- → P5
Whiteboard: [gfx-noted]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: