Bug 165694 – Allow variable-refresh-rate requestAnimationFrame, and refresh rate discoverability

• Component: Animations
• Status: NEW

[Simon Fraser (smfr)]

For power saving, we should investigate the gains from throttling rAF to 30fps (or lower) in cross-origin iframes.

[Simon Fraser (smfr)]

rdar://problem/28812757

[Radar WebKit Bug Importer]

<rdar://problem/30725494>

[mdrejhon]

There is a known side effect.
An additional consideration is EMBED animations.  

For example, a monitor review (BlurBusters GSYNC Preview #1) on one website embeds a 30fps-versus-60fps animations as well as VRR animations (TestUFO Stutter animation).   

Example 30fps-versus-60fps animation: http://www.testufo.com
Example EMBED of above animation: http://forums.blurbusters.com/viewtopic.php?f=19&t=143&p=1124

If throttling to 30fps, then the convenience of embedding scientific TestUFO animations (e.g. www.testufo.com/eyetracking and others) becomes inaccurate.  This is used very frequently by certain types of websites, including mine (BlurBusters/TestUFO).

Just like some websites embed 60fps YouTube videos, there are now some websites that embed intentional-60fps animations (e.g. 30fps versus 60fps animations).  There is also a 120fps-versus-60fps-versus-30fps animation that works in Chrome and FireFox, and it also works embedded.

(On the 120Hz requestAnimationFrame topic, see https://bugs.webkit.org/show_bug.cgi?id=173434 ...)

The throttle idea may be well-intended rationale, probably is the worry of advertisements eating up battery power. While a solution could be warranted, a blanket browser-engine decision to throttle animations has unintended consequences.

[mdrejhon]

(For those not familiar with me: I own BlurBusters/TestUFO -- and am an Invited Expert, W3C Web Platform Working Group, with an accepted commit to HTML 5.2 DRAFT 8)

[mdrejhon]

I am working on potential modifications to HTML 5.3 standards, and would like your comments.  I have also reached out to other parties including Microsoft (Edge) and Google (Chrome) to hear feedback.

On W3C's html tracking system:
PHASE 1: https://github.com/w3c/html/issues/375#issuecomment-306591154 
PHASE 2: https://github.com/w3c/html/issues/375#issuecomment-306603305

First phase does not require API changes, while Phase 2 requires API changes.

The impression is there are conflicting goals:
- Performance (120fps)
- Battery savings
- High-framerate advertisements

An emerging consensus view is occuring: I even agree with this:
There is a legitimate need for a throttle (e.g. idle mobile, or low battery, no user activity, ad blocker modules, etc) but this should not be baked-in at the WebKit codebase level as a blanket limit.

CONSENSUS: Discoverability is a mandatory requirement if a throttle is added to browser standards.

To allow awareness of modules, the throttle should be exposed to software.  In addition to refresh rate discoverability (i.e. screen.hz) there should be throttle discoverability, through some property of some kind (e.g. '.getCurrentAnimationFrameFrequency()" or via "screen.animationrate").   This reportability should also apply to video, not just rAF().   e.g. 60fps videos being played at a coarse 30fps due to a screen running at lower refresh rate during power saver, etc.

[Simon Fraser (smfr)]

Thank you for the updates. Since the throttling change was landed in r215070 I'm going to retitle this bug.

[mdrejhon]

(In reply to Simon Fraser (smfr) from comment #6)
> Thank you for the updates. Since the throttling change was landed in r215070
> I'm going to retitle this bug.

Thanks. Ideally, this should be split into multiple smaller tasks
-- discoverability can apply to non-variable-refresh-rate situations.

While understandable due to power consumption reasons, it is disappointing to hear r215070 has broken some websites in the Safari browser (framerate comparison demos), the important thing is a consensus is formulated quickly so that embedded animations can adapt accordingly (e.g display a properly optimized animation, display a button to launch into another tab for higher rate non-embedded demo).

Variable refresh rate support is a bigger change than simply adding discovarability of refresh rate and current throttle (two different values)

I propose splitting this into two separate tasks.  

1. Quickly adding simple discoverability ASAP (even initially with a "webkit" prefix during prototyping)
2. Eventually later, add full support for variable refresh rate.  

Meaning begin some Phase 2 entries before doing Phase 1.  I'll talk to W3C about splitting #375 into two separate, more independent tasks.   At the same time, this doesn't preclude quickly adding a "webkit" prefixed property or method for quicker discoverability now -- given browser animations (including TestUFO) are now being used to create peer-reviewed scientific papers (e.g. http://www.blurbusters.com/motion-tests/pursuit-camera-paper ...)