[Webkit-unassigned] [Bug 165694] Allow variable-refresh-rate requestAnimationFrame, and refresh rate discoverability

[bugzilla-daemon at webkit.org]

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

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

-- 
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/c127708b/attachment.html>