[whatwg] asynchronous JSON.parse
Glenn Maynard
glenn at zewt.org
Fri Mar 8 06:42:19 PST 2013
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
More information about the whatwg
mailing list