New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 485600 link

Starred by 40 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocking:
issue 875308
issue 599152



Sign in to add a comment

Investigate dropping {everything, main thread, cross origin frames} down to 30 fps or lower

Project Member Reported by skyos...@chromium.org, May 7 2015

Issue description

Create a prototype for dropping down to 30 fps if we can't make 60 fps.
 
Labels: -Hotlist-Scheduling Cr-Blink-Scheduler
Labels: -Cr-Blink-Scheduler Cr-Blink-Scheduling
Status: Available
Cc: -jdduke@chromium.org alexclarke@chromium.org
Summary: Investigate dropping {everything, main thread, cross origin frames} down to 30 fps or lower (was: Create a prototype for dropping down to 30 fps)
Blocking: 599152
Cc: tdres...@chromium.org
Cc: alexsuvo...@unity3d.com ang...@floored.com
I think an opt-in 30 fps mode is valuable, but automatically dropping to 30 fps feels like a bad idea.

My argument is that if you're interacting with the page via a user gesture, the latency matters and it doesn't seem to be possible to construct a case where 30 fps feels better.

See this page: https://jsbin.com/geqasoyiqe/edit?js,output

This example been gamed to be the optimal situation for 30 fps. It simulates a workload that always completes in the 30 fps budget (i.e., the 30 fps pane never janks). For the 60 fps pane, you can adjust the probability that you'll complete your work in the 60 fps budget. If you set it to 0.0, it's the same as the 30 fps pane, if you set it to 1.0, it's pure 60 fps. It seems clear to me that no matter how bad you make it for the 60 fps case, it always looks as good as or better than the 30 fps version.

I think the situation is different for motion that's not tied to a user gesture. See, for example https://jsbin.com/goxahogiyu/edit?html,css,output

In this case, the hiccups in the smooth motion that we expect makes the 60 fps pane look worse.

Since scrolling is tied to user gestures and is so predominant on the web, choosing a fallback mode that is better only for animations seems like a bad move. On the other hand, it does make a lot of sense to provide developers creating animated experiences (eg, game developers) an explicit API for opting into 30 fps. The situation is also different during page load.

There's a good chance I messed up when creating my example pages -- please let me know if the examples or my reasoning is faulty.

Comment 8 by junov@chromium.org, Apr 15 2016

Had an interesting conversation with several game developers at a conference yesterday. The feedback I got is that though it is desirable to drop the frame rate to 30fps, or even 20fps to maintain regularity, it would be best for this behavior to be controllable, or at least standardized. Games are already doing hacks to self-diagnose their rendering performance and to self-throttle, and there is a serious concern that an attempt to achieve the same thing by means of a user agent intervention would interfere with existing mechanisms in web games and would just lead to greater browser interoperability issues.
I have already mentioned this on the related issue, but I am wondering if the low level API for the raster status has been considered? With combination of vsync period, time to the next vsync and high-resolution setTimeout, JavaScript application itself would be able to fully control the rAF behavior, whether by arbitrary dropping its fps or adjusting the animation to vsync.
#9: could you explain in a little more detail what that API would do?

One of the options we've been thinking of recently is to give developers a choice between "smoothness" and "low latency". Right now Chrome is essentially always optimizing for low latency, but if the developer chose smoothness, we could automatically adjust them to 30 fps if necessary. Importantly they could still run at 60 fps if the hardware is up to the task.
#10: on the lowest level the API would return IDirect3DDevice::GetRasterStatus to get the current scanline, IDirect3D::GetAdapterDisplayMode to get the total number of scanlines and the refresh rate. This information should be sufficient to implement your own WaitForVerticalBlank. The browser API can simplify this all a bit and eliminate the unnecessary information, and just directly provide precalculated time to the next vsync and vsync interval. Unlike requestAnimationFrame which does not correlate with vsync on fps lower than monitor refresh rate, such low level API would provide you with the real device information. You would be able to reliably determine whether the last vsync has been missed due to the thread being busy, and determine when the next vsync comes. If you predict that next vsync will most probably be missed (using the duration of the previous loop iteration), then you can shift the time used to generate the animation appropriately in advance. Even if such a loop finishes before the next vsync, you will still be able to explicitly miss the next vsync using setTimeout (this should be equivalent to dropping fps to 30) so that your generated animation matches the actual rendering time. This can only be achieved if you get real information from the device.
Thanks for the explanation. It seems to me like just observing vsync won't be enough, because the rest of the browser and the GPU will still try to race for the next vsync. In other words, the time at which the new frame was generated doesn't necessarily determine when it is going to be presented.\

We'd also need an API which is implementable on all the relevant platforms, so this will probably need to be a more high level.
#12 Indeed you are not able to reliably predict when the computed animation is going to be displayed if you just use requestAnimationFrame and your fps is lower than monitor refresh rate. Normally it happens that you render the previous frame and not the displayed one. This setup only works well under assumption that frames are rendered regularly with fixed fps, so the rendering always has the same latency. In other words, in such setup you can reliably predict the exact time of the next rendered frame.

However, this is not the only possibility. If you get the information about the current scanline status, you will also be able to predict the next rendering time even if rendered frames are not regular. This gives you full control over the situation, you can drop frames when necessary (going down to 30 fps) without having to rely on the browser rAF, or you can adjust the animation in such a way that it matches the non-regular frame display.

You are right, such device information may not be available on several platforms.
We're thinking it would be nice to be able to test out an API for throttling frame production in a more constrained space before looking at applying it to rAF in general.

Alex, is Unity planning on using OffscreenCanvas (https://wiki.whatwg.org/wiki/OffscreenCanvas)? If we were to ship OffscreenCanvas with a way of throttling frame production, would that be useful?

Is OffscreenCanvas useful for gaming if it doesn't provide access to user input?
Cc: junov@chromium.org ojan@chromium.org sunn...@chromium.org simonh...@chromium.org skyos...@chromium.org
 Issue 522983  has been merged into this issue.

Comment 16 by ojan@chromium.org, Oct 12 2016

Cc: seththompson@chromium.org ikilpatrick@chromium.org dk...@chromium.org
Project Member

Comment 17 by sheriffbot@chromium.org, Oct 12 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)

Comment 19 by ojan@chromium.org, May 8 2018

Cc: -ojan@chromium.org
Cc: -junov@chromium.org
Labels: -Type-Bug Type-Feature
Blocking: 875308

Sign in to add a comment