W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] Proposal: requestBackgroundProcessing()

From: Ashley Gullen <ashley@scirra.com>
Date: Thu, 20 Feb 2014 16:23:05 +0000
Message-ID: <CAABs73jLLca2pmjFQAqf4OkmHxKsbzLETVWE0iAaVXyoUYXWkA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
Isn't setTimeout also clamped to 1s in the background? This alone would add
so much latency as to effectively hang the game anyway.




On 20 February 2014 16:18, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen <ashley@scirra.com> wrote:
> > We're building a browser-based P2P multiplayer engine on top of WebRTC
> > DataChannels. You can try out our work-in-progress here:
> > http://www.scirra.com/labs/multiplayer/test1/
> >
> > The first player in to a room is assigned the host, and all other
> > subsequently joining peers connect to the host with WebRTC DataChannels
> and
> > start exchanging game data. Like all responsible HTML5 games, it runs
> based
> > on a requestAnimationFrame loop.
>
> I think this is your problem.  rAF isn't a replacement for setTimeout,
> it's a variant designed to better solve the timer problem *when you
> want to be synced to the screen*.
>
> If you're doing network-management work, that has nothing to do with
> the screen refresh rate, and shouldn't be associated with it.  Just
> run a normal setTimeout loop instead.
>
> (If people used rAF for what it was *intended* for, we could probably
> have stopped firing it *entirely* when the window isn't visible.
> Instead, we had to compromise with the 1s refresh rate instead.)
>
> ~TJ
>
Received on Thursday, 20 February 2014 16:23:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:16 UTC