[Webkit-unassigned] [Bug 173434] Support for 120Hz requestAnimationFrame

[bugzilla-daemon at webkit.org]

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

--- Comment #28 from mdrejhon <mark at blurbusters.com> ---
Thanks for the tip, I need to study if our team is incorrectly using the new APIs, or if we've discovered a major inconsistency between browsers in their timestamp handling between different browsers in Web Animation API  (far more inconsistent than requestAnimationFrame).  

We will now do further research on a wider number of browsers.

However, a scientific correction:

> If other browsers are passing a timestamp to requestAnimationFrame() which is not just the "now" timestamp from the HTML spec, and this different timestamp gives you additional information, then you should lobby for those browsers to standardize whatever they are doing.

Actually -- it's the same thing when it hits an equilibrium of framerate=Hz.

Buring framerate=Hz situation, now() automatically settles to an equilibrium where now() is identical to refresh cycle time.   One and the same thing, during max frame rat, it becomes is identical in the callback.  It's a synonym during framerate=Hz

now() is synonymous with refresh cycle timing when framerate=Hz, because of the way VSYNC (which existed since 1920s Biard/Farnsworth analog TVs) is a defacto comma-separator between refresh cycles.  

(VSYNC = Vertical Synchronization = a separator between refresh cycles, generated by all analog and digital video outputs over the last 100 years).  Apple terminology sometimes call this BeamSync or displaySyncEnabled, but they're all synchronized to the VSYNC signal in the GPU -- it's the refresh cycle metronome.

VSYNC is how Apple/Windows/Android/iOS synchronizes framerate=Hz for things like smooth scrolling and jank-free animations.

SITUATION 1
When (framerate != Hz), it deviates so much that it signals instantly like a christmas tree within 1/Hz (i.e. reliable missed frame detection logic is easy to write with requestAnimationFrame().  The interval jitters, e.g. a dropped frame is 2/Hz sec between timestamps rather than 1/Hz sec between timestamps.

SITUATION 2
When (framerate == Hz), it settles into an equilibrium that almost perfectly relative-time aligns to the VSYNC in the GPU (to an error margin of +/- 0.1 to 1ms at https://www.testufo.com/animation-time-graph ...) and it is easy to automatically decide that it's the current display refresh rate, because the interval doesn't jitter at all.

Because of the fact that scientific equilibrium (2+2=4 is always true independently of OS), now() is identical to refresh cycle timestamps during SITUATION 2.   Refresh rate detection is reliable in requestAnimationFrame() 

The way VSYNC ON in many APIs (VSYNC ON, VertSync ON, InVBlank=true, BeamSync ON, or whatever API terminology is used) -- works is that it blocks frame presentation (all APIs in all OS that synchronizes to the 100-year-old VSYNC that exists in all analog and digital video signals -- it's a 100% OS and vendor independent sync).  So, when things are running maxed-out, timestamps almost perfectly aligns to refresh cycles.  It's just scientific certainity, like 2+2=4, so in the spec, "now()" is identical to "refresh cycle timestamps" simply because of science of VSYNC.

Conculsion: There is nothing to change in the requestAnimationFrame() standard, as it works perfectly now in all major HTML5 browsers (even in Safari too, at least at 60Hz).  I'm kind of surprised you mentioned that, but perhaps it was from your unfamiliarity with a 100-year-old refresh cycle separator signal -- but at least now you know now() in the callback is generally synonymous to refresh cycle timestamps when things are running flat-out max framerate.

That's why we're able to do refresh cycles so precisely in TestUFO, because we're very familiar with the VSYNC science (Blur Busters specializes in the Present()-to-Photons black box).

-- 
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/20220804/8e6fe98f/attachment-0001.htm>