WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
Bug 165694
Allow variable-refresh-rate requestAnimationFrame, and refresh rate discoverability
https://bugs.webkit.org/show_bug.cgi?id=165694
Summary
Allow variable-refresh-rate requestAnimationFrame, and refresh rate discovera...
Simon Fraser (smfr)
Reported
2016-12-09 15:27:05 PST
For power saving, we should investigate the gains from throttling rAF to 30fps (or lower) in cross-origin iframes.
Attachments
Add attachment
proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1
2016-12-09 15:27:52 PST
rdar://problem/28812757
Radar WebKit Bug Importer
Comment 2
2017-02-26 17:07:55 PST
<
rdar://problem/30725494
>
mdrejhon
Comment 3
2017-06-17 18:51:23 PDT
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
Comment 4
2017-06-17 18:54:50 PDT
(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
Comment 5
2017-07-12 16:02:45 PDT
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)
Comment 6
2017-07-12 16:12:15 PDT
Thank you for the updates. Since the throttling change was landed in
r215070
I'm going to retitle this bug.
mdrejhon
Comment 7
2017-07-12 16:47:30 PDT
(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
...)
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug