[Webkit-unassigned] [Bug 165694] Consider throttling requestAnimationFrame in cross-origin iframes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=165694

--- Comment #5 from mdrejhon <mark at blurbusters.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170712/76b4f2c2/attachment-0001.html>