W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2013

Re: [whatwg] asynchronous JSON.parse

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 8 Mar 2013 08:42:19 -0600
Message-ID: <CABirCh8iddFb6rvvpRnfUtBA2f3aU3pbs4MmrU2OKD5_0XX+5A@mail.gmail.com>
To: David Rajchenbach-Teller <dteller@mozilla.com>
Cc: whatwg@whatwg.org, Tobie Langel <tobie.langel@gmail.com>
On Fri, Mar 8, 2013 at 4:51 AM, David Rajchenbach-Teller <
dteller@mozilla.com> wrote:

> a. saving the state of the current region in an open world RPG;
> b. saving the state of an ongoing physics simulation;

These should live in a worker in the first place.

c. saving the state of the browser itself in case of crash/power loss
> (that's assuming a FirefoxOS-style browser implemented as a web
> application);

I don't understand this case.  Why would you implement a browser in a
browser?  That sounds like a weird novelty app, not a real use case.  Can
you explain this for people who don't know what "FirefoxOS" means?

d. backing up state and history of the browser itself to a server
> (again, assuming that the browser is a web application).

(This sounds identical to C.)

Similarly, for a 3d game, until workers can perform some off-screen
> WebGL, I suspect that a considerable amount of complex game data needs
> to reside on the main thread, because sending the appropriate subsets
> from a worker to the main thread on demand might not be reactive enough
> for 60 fps. I have no experience with such complex games, though, so my
> intuition could be wrong.

If so, we should be fixing the problems preventing workers from being used
fully, not to add workarounds to help people do computationally-expensive
work in the UI thread.

Glenn Maynard
Received on Friday, 8 March 2013 14:42:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:56 UTC