[Webkit-unassigned] [Bug 173434] New: Support for 120Hz requestAnimationFrame (Compliance with HTML 5.2 DRAFT 8)

[bugzilla-daemon at webkit.org]

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

            Bug ID: 173434
           Summary: Support for 120Hz requestAnimationFrame (Compliance
                    with HTML 5.2 DRAFT 8)
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Canvas
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mark at blurbusters.com
                CC: dino at apple.com

The 120Hz iPad only supports 60fps/60Hz at http://www.testufo.com and http://www.vsynctester.com

Precedent:
Currently, FireFox, Chrome, and even Edge/IE all supports animation rates greater than 60Hz since 2013, and both Chrome/FireFox browsers work at 240fps on the new true-240Hz gaming monitors (e.g. Acer Predator XB252Q, Acer Predator XB272Q, ASUS ROG PG258Q, AOC AGON AG251FZ, BenQ Zowie XL2540, BenQ Zowie XL2546).  Currently, Chrome/FireFox has no cap on the maximum possible refresh rate, and a test on a laboratory 480Hz display resulted in 480fps, and enough performance exists to run at >2000 callbacks to requestAnimationFrame in full-screen simple animations on top-end desktop GPUs (chrome --disable-gpu-vsync command line option)

HTML 5.2 standard:
A recent change was made to HTML 5.2 (DRAFT 8) -- https://github.com/w3c/html/issues/785 -- whereupon there should not be a refresh rate limitation on requestAnimationFrame() during unconstrained situations.  

Minimum Possible Compliance situation:
This specifically declares a lowest common denominator: When the iPad is in a unconstrained situation (no performance limit, temperatures are cool, power plugged into iPad charger, and not in a user-activated power-saver mode), the iPad needs to follow HTML 5.2 DRAFT 8 where animations "MUST NOT" (RFC2119) have a refresh-rate cap during system-unconstrained situations.

Preferred compliance situation:
The ideal situation is that 120fps will also run on battery power whenever CPU/GPU overheads are small enough, to permit people to view motion tests to realize the benefits of 60Hz vs 120Hz.  Such as http://www.testufo.com and the multiple selectable motion tests (selectable at upper right corner).   There are good reasons to throttle requestAnimationFrame (background, offscreen, battery low, high resource utilization, etc) but by default, low-overhead animations (e.g. requestAnimationFrame executing in less than 1ms) should be permitted to run on battery power at full sync to refresh rate.

-- 
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/20170615/63e88c35/attachment.html>