Bug 274372 – Permission API for 120Hz Support instead of manual setting "Prefer Page Rendering Updates Near 60fps"

• Status: RESOLVED
• Resolution: MOVED
• Component: Compositing

[mdrejhon]

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)

[mdrejhon]

SOLUTION EXAMPLE

A possible Apple Safari specific permission-request message could be:


"Webpage is requesting permission to use high frame rate (ProMotion) animations.  This may consume more battery power.  Allow?  Yes/No"

[mdrejhon]

(In reply to mdrejhon from comment #1)
> 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.  

Also this is the compromise scenario.

PREFERRED SCENARIO 

I would prefer to detect refresh rate immediately like I can on all major Windows browsers.  Reasoning is that it's easy to do on Windows, and you can detect screen resolution on the majority of platforms.  So it would almost be a no-brainer.  However, I've offered the compromise to hide refresh rate discovery behind the HFR Permission Request.

Ideally I'd like to at least know if the screen is "60 Hz" versus "Above 60 Hz", via some discovery mechanism whether or not the browser is framerate capped or uncapped.  Even if it's simply detecting it simply via a non-immediate-fail on a HFR Permission Request.

[Marcos Caceres]

Hi mdrejhon,

Would you mind copy/pasting your proposal to the WICG's Proposals repo? 

https://github.com/wicG/proposals


That's usually where proposals like this start and the WICG Chairs can help you get some visibly on it from other folks in the W3C and WHATWG community.

We could also discuss general alternates for standardization there.

[Marcos Caceres]

Also, it would be good to just talk about this in general terms... this could theoretically be the case with any user agent or OS... it's not necessary an Apple specific problem.

[Marcos Caceres]

mdrejhon, the WICG provides a simple to follow template. You shouldn't need any special expertise or anything to add what you wrote over on:

https://github.com/whatwg/meta/issues/158

Just copy/paste the interesting bit from there.

I chair the WICG. I can help you out from there.

[mdrejhon]

(In reply to Marcos Caceres from comment #3)
> Hi mdrejhon,
> Would you mind copy/pasting your proposal to the WICG's Proposals repo?
> https://github.com/wicG/proposals

Thanks. I'll try to get to this within a week (ish).  


(In reply to Marcos Caceres from comment #4)
> Also, it would be good to just talk about this in general terms... this
> could theoretically be the case with any user agent or OS... it's not
> necessary an Apple specific problem.

I agree it would be appropriate for any device that has a frame rate throttle. 

Though AFAIK as of 2024, there are no longer any major browsers that have a mandatory refresh rate throttle in default installs anymore (enforced even during optimal conditions).  The last ones were IE and Old Edge 105 Hz internal cap.  The only throttle is external (OS setting refresh rate lower during a battery saver mode).

[Marcos Caceres]

Thanks, mdrejhon! Please ping me here once it's up and I'll take a look.

[Radar WebKit Bug Importer]

<rdar://problem/128772602>

[Jeffrey Blanz]

With game mode coming to iOS 18 and iPadOS 18 I think this would be a great time to add this to this proposal.

It could be called “Game Mode API”.

The API could include all the feature mentioned above, while also enabling the system game mode on macOS, iOS, and iPadOS. This could also be added to visionOS for gaming on there. Although visionOS has no game mode, it could be something that Apple adds later.

[Jeffrey Blanz]

I have created a proposal for this here. I used many of the details above.

https://github.com/WICG/proposals/issues/165

[mdrejhon]

Thank you!  The Game Mode Permission or the HFR Permission is sorely needed.

[Marcos Caceres]

Resolving as moved to the WICG.

[mdrejhon]

Thanks, Jeffrey, for moving this to the correct venue!  I'll follow up soon.