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 21:29:47 +0000
Message-ID: <CAABs73j0U+58zbQcn9oQ4hiDS5zzsUu6K=0FaWxGEYV2o9tLfw@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>, James Robinson <jamesr@google.com>
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()?

On 20 February 2014 18:50, Glenn Maynard <glenn@zewt.org> wrote:

> On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> This sounds like work that should be done in a worker.  Worker timers
>>> aren't throttled when in the background, and this is exactly something
>>> workers are for.
>> Is WebRTC available in a worker?
> I don't know, but if not, fixing that is probably closer to the right
> direction than letting people run fast timers in minimized UI threads.  If
> this is just messaging of game state, he could probably do just relay that
> through the UI thread, so the game simulation still takes place in a worker.
> --
> Glenn Maynard
Received on Thursday, 20 February 2014 21:30:17 UTC

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