[whatwg] asynchronous JSON.parse

[Glenn Maynard]

On Fri, Mar 8, 2013 at 4:51 AM, David Rajchenbach-Teller <
dteller at 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