[Webkit-unassigned] [Bug 274372] New: Permission API for 120Hz Support instead of manual setting "Prefer Page Rendering Updates Near 60fps"

[bugzilla-daemon at webkit.org]

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

            Bug ID: 274372
           Summary: Permission API for 120Hz Support instead of manual
                    setting "Prefer Page Rendering Updates Near 60fps"
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Enhancement
          Priority: P2
         Component: Compositing
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mark at blurbusters.com
                CC: simon.fraser at apple.com

NOTE: I only have experience with W3C, and not WHATWG, so can somebody contact me at mark [at] blurbusters.com to create a WHATWG proposal for High Frame Rate (HFR) Permission.  I am willing to help team-up with a WHATWG member to submit a solution for this new UX problem created by Apple as they currently solve https://bugs.webkit.org/show_bug.cgi?id=173434 "

WHO USES 120FPS HFR

HFR affects everything that wants to run at above 60fps:
- Video
- WebGL
- CANVAS
- Animation Timing
- Smooth pan/scroll (manual and javascript-automatic)


PROBLEM

Certain devices such as Apple Devices requires users to manually go to an obscure screen to change a setting to render at above 60 frames per second.  

This is very user unfriendly, and interferes with marketing 120Hz.  This also hurts Apple's sales of 120Hz, if I cannot show benefits of 120Hz on the go as easily on a friend's iPhone Pro or iPad Pro, and they don't want me to fiddle with their settings.  Apple loses sales because of this.  Users lose trust in 120Hz. 

This affects gaming websites, motion testing websites, scientific applications, even Apple themselves trying to advertise the benefits of high frame rates to help sell more "Pro" devices".

120fps was less visible on LCD so this a low priority, due to poor performance of LCD.  However, with the dramatic visibility increase of 60-vs-120 on OLED displays (even TechSpot discovered 240Hz OLEDs was much better than expected for office productivity).  Even 120Hz-vs-480Hz on OLED was recently scientifically discovered to be more human-visible than 60-vs-120 on LCD, due to a geometrics-style effect (4x vs 2x) during fast motion.

But a major problem is battery powered devices eat more power at 120fps and beyond.



KNOWN CONCERNS 

- Battery consumption problems
- Unconfigurable PWAs ( https://bugs.webkit.org/show_bug.cgi?id=272226 )
- Annoying ad banners running at too high a frame rate
- Privacy concerns about letting websites discover the exact refresh rate of your display (even though APIs already exist to discover resolution, etc).  
- Websites instructing users to change a setting (Prefer Page Rendering Near 60fps)
- Friends of Apple fans not allowing them to change settings on their other devices for show-and-tell (more difficult to market benefits of 60-vs-120 by word of mouth)
- Excessive permission requests


SOLUTION: HFR Permission API

HFR = High Frame Rate = Frame rates permitted to match maximum Hz

A proposal to use the Permission API to ask for permission to use HFR animations. When a website asks for HFR permission, the browser will popup a message asking the user for permission to use a higher frame rate (matching maximum refresh rate).  The HFR permission popup will only work if it's a same-origin or permitted-origin (so ad banners can never request it).


SOLUTION SEQUENCE

1. Webpage must ask for permission. "Webpage requests High Frame Rate / High Refresh Rate?  Allow/Deny?" or similar.
2. If already running at HFR, then permission is automatically granted without popup (e.g. like fullscreen API request while already running fullscreen)
3. If user denies, no change to frame rate cap (60fps) occurs.
4. If user accepts, a callback event is called (TBD) to inform framerate cap is removed.

Note: By default, webpage MAY NOT discover max Hz if the page is currently capped (e.g. Limit to 60fps), this may resolve privacy concerns if Apple is concerned about webpages discovering refresh rates of visitors.  However, implementors MAY provide a separate discovery mechanism for refresh rate, much like existing discovery mechanisms for screen resolutions.  


POSSIBLE PIGGYBACK?

In theory, this could be part of the existing "Windows Management API" permission request, to discover the refresh rates of all screens and/or to unlock frame rate caps.  However, thought is needed for single-screen mobile devices.  However, "Window Management API" could still be the mechanism to discover the refresh rates of all individual screens (otherwise, advance refresh rate discovery is not permitted otherwise)

-- 
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/20240520/4b7565d3/attachment.htm>