[whatwg] asynchronous JSON.parse

[David Rajchenbach-Teller]

On 3/8/13 3:42 PM, Glenn Maynard wrote:
> On Fri, Mar 8, 2013 at 4:51 AM, David Rajchenbach-Teller
> <dteller at mozilla.com <mailto: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.

Ideally, yes. The question is whether this is actually feasible.
Also, once we have a worker thread that needs to react fast enough to
provide sufficient data to the ui thread for animating at 60fps, this
worker thread ends up being nearly as critical as the ui thread, in
terms of jank.

In both scenarios, the worker has two tasks:
1. providing data in real-time to the ui thread;
2. extracting the relevant sent of data and somehow saving it.

In the case of large data, I believe that task 2. may be quite
disruptive to task 1. So we need an efficient and/or asynchronous way to
send large amounts of data to another worker for processing and saving.

If I am correct, this means that we need some mechanism to provide
efficient serialization of non-Transferable data into something
Transferable. I tend to believe that this would fit nicely as a
JSON.serialize, but there may be other, better, manners of doing so.


>     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?

Seriously?
FirefoxOS [1, 2] is a mobile operating system in which all applications
are written in JavaScript, HTML, CSS. This includes the browser itself.
Given the number of companies involved in the venture, all over the
world, I believe that this qualifies as "real use case".

I also seem to remember that several well-used iOS browsers are
developed as web applications wrapped as native binaries.

Finally, there is no reason to assume that a web browser, whether
desktop or mobile, cannot be developed as a HTML-based user interface
around one or more <iframe>. The same issue arises with all these
variants of the same scenario.

>     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.)

Nearly, yes. I just wanted to point out that not all examples were
related to writing to a file or database.

> 
>     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.

Fine with me. However, as mentioned above, moving things off the main
thread is not a magic bullet.

Best regards,
 David

[1] http://en.wikipedia.org/wiki/Firefox_OS
[2] http://www.mozilla.org/en-US/firefox/partners/


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla