[whatwg] asynchronous JSON.parse

[David Bruant]

Le 08/03/2013 13:34, David Rajchenbach-Teller a écrit :
> I fully agree that any asynchronous JSON [de]serialization should be
> stream-based, not string-based.
>
> Now, if the main heavy duty work is dealing with the large object, this
> can certainly be kept on a worker thread. I suspect, however, that this
> is not always feasible.
>
> Consider, for instance, a browser implemented as a web application,
> FirefoxOS-style. The data that needs to be collected to save its current
> state is held in the DOM. For performance and consistency, it is not
> practical to keep the DOM synchronized at all times with a worker
> thread. Consequently, data needs to be collected on the main thread and
> then sent to a worker thread.
I feel the data can be collected on the main thread in a Transferable 
(probably awkward, yet doable). This way, when the data needs to be 
transfered, the transfer is fast and heavy processing can happen in the 
worker.

> Similarly, for a 3d game, until workers can perform some off-screen
> WebGL
What if a cross-origin or sandbox iframe was actually a worker with a 
DOM? [1]
Not for today, I admit.
"Today", canvas contexts can be transferred [2]. There is no 
implementation of that to my knowledge, but that's happening.

> 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.
I share your intuition, but miss the relevant expertise too. Let's wait 
until people complain :-) And let's see how far transferable CanvasProxy 
let us go.

David

[1] 
https://groups.google.com/d/msg/mozilla.dev.servo/LQ46AtKp_t0/plqFfjLSER8J
[2] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable