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
