[whatwg] Proposal: requestBackgroundProcessing()

[Ashley Gullen]

Since it's a peer-to-peer engine, the user acting as the server is also a
participant in the game. This means the server is also running the full
game experience with rendering and audio. The game logic is tied to rAF,
since we intend to step the world once per screen draw, including for the
player acting as a server. It looks like the server is caught between
running in the UI thread and hanging when in the background, or running in
the worker and not having a straightforward way to provide the rendering
and audio game experience for the host player.

One solution is to make web workers able to access many of the same APIs
the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then
it might be practical to move a full game engine in to a worker. If that is
planned, I guess there is no need for a new feature.

Ashley




On 20 February 2014 21:55, Glenn Maynard <glenn at zewt.org> wrote:

> On Thu, Feb 20, 2014 at 3:29 PM, Ashley Gullen <ashley at scirra.com> wrote:
>
>> There's a lot of worker features that aren't widely supported yet, like
>> rendering to canvas with WebGL and 2D, Web Audio support, inputs, various
>> APIs like speech and fullscreen, so I don't think that's practical right
>> now. I guess that's not a reason to standardise a new feature, but is there
>> not at least a workaround for the mean time? Are workers able to wake the
>> UI with postMessage()?
>>
>
> You were talking about running the server of a multiplayer game.  Other
> than communicating with other clients, it doesn't need any of that, right?
>  Those are all client-side behaviors.
>
> You can send a message to the UI thread.  I didn't suggest that, since it
> feels like an arms race of trying to sidestep browser behavior.  It may not
> matter, since the common things they're trying to stop are probably things
> like never-ending animation timers running when you can't even see it (who
> have no reason to drive their timers from a worker to bypass the timer
> throttling), but I'd recommend trying to move your actual server logic into
> a worker.
>
> --
> Glenn Maynard
>
>