Re: [whatwg] Worker requestAnimationFrame

We build a major HTML5 game engine, and I feel the deadline approach is
unsuitable for gaming. Games often do heavy CPU work to run the game logic
before drawing. (Please do not drag me in to arguments over time stepping;
stepping less often than rAF does not look smooth, and stepping more often
wastes CPU and battery, or the CPU is simply not fast enough to fit more
than one step in 16ms.) If a game misses any kind of deadline, it can't
just choose to not miss the deadline. We think the best behavior in that
case is to drop to half v-sync rate. Note that many top console games
specifically target 30 FPS and no higher[1]. Many of our users have asked
for this behavior[2]. Running at say 45 FPS looks uneven and is perceived
as janky due to the irregular screen update, whereas 30 FPS (i.e. half
v-sync rate) is perceived as more steady and even, despite the technical
performance being worse.

We have tried to implement half-vsync rate ourselves in the past by simply
ignoring alternate rAFs, but in practice it looked terrible - I guess we
broke implementation-defined heuristics that expect every rAF call to do a
similar amount of work. I think it would be more useful if we could
indicate to the browser what we want to happen given that we *expect* to
miss the deadline, either:
1) display ASAP and callback again ASAP (this appears to be the current
behavior and allows uneven framerates like 45 FPS)
2) drop to half rAF rate (producing a steady 30 FPS on a 60 Hz display).

I understand this may be left as implementation-defined, but I guess there
may be valid use cases for "display ASAP" as well (VR?), so perhaps the
spec should be extended to allow both cases?

When it comes to rAF in a worker, for the reasons above I do not see the
point in any divergence from what the existing main-thread rAF does, unless
both are changed. If both are changed I hope it takes in to account
half-vsync mode. If main-thread rAF is not changed, then the rAF in a
worker should fire simultaneously with the main-thread rAF (as if
main-thread rAF posted a message to the worker, minus the latency of
posting a message) such that a game engine running in a worker can align
with the main window painting.


[1]
http://www.gamespot.com/articles/fallout-4-will-run-1080p-30fps-on-ps4-xbox-one-pc-/1100-6428362/
[2] See crbug.com/461719 which has 53 stars



On 19 August 2015 at 22:32, Justin Novosad <junov@google.com> wrote:

> On Wed, Aug 19, 2015 at 5:14 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> > On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick <vollick@chromium.org>
> wrote:
> >
> >> On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad <junov@google.com>
> wrote:
> >>
> >>> On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers <rbyers@chromium.org>
> >>> wrote:
> >>>
> >>>> Sounds great to me.  I agree this is an important scenario.  *Ian*,
> >>>
> >>>
> >>>> thoughts?
> >>>
> >>>
> >> I would certainly like to see requestAnimationFrame in a worker, but
> >> there is more risk of falling out of step with vsync in a vanilla worker
> >> that has access to APIs that are dangerous from a performance point of
> >> view. It would also be nice to run a worker with rAF on an elevated
> >> priority thread (or maybe even the compositor thread), but that would
> be a
> >> bad idea if it can do stuff like synchronous IO.
> >>
> >
> > I fear a proliferation of different kinds of restricted Workers that
> would
> > make it hard to handle multiple kinds of callbacks in a single Worker, so
> > I'd rather not introduce a new restricted kind unless it's absolutely
> > necessary. I think it would be fine to support rAF in a general
> > DedicatedWorker and then later, if absolutely necessary, provide an
> > elevated-priority Worker with restricted API.
> >
> > After implementing rAF for DedicatedWorker, the first slow-script
> > mitigation I'd like to introduce is the "you missed your frame deadline"
> > event that we've been talking about for a whlie.
> >
>
> In the requestIdleCallback proposal (
> https://w3c.github.io/requestidlecallback/ ) a deadline argument is passed
> to the callback. That's an idea we could apply here as well.  Not sure
> whether it is better or worse than using an event.
>
>
> >
> > Rob
> > --
> > lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe
> uresyf
> > toD
> > selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> > rdsme,aoreseoouoto
> > o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> > lurpr
> > .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> > esn
> >
>

Received on Thursday, 20 August 2015 11:02:53 UTC