Re: [whatwg] asynchronous JSON.parse

On 3/8/13 1:59 PM, David Bruant wrote:
>> 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.

Intuitively, this sounds like:
1. collect data to a JSON;
2. serialize JSON (hopefully asynchronously) to a Transferable (or
several Transferables).

If so, we are back to the problem of serializing JSON asynchronously to
something transferable. Possibly an iterator (or an asynchronous
iterator == a stream) of ByteArray, for instance.

The alternative would be to serialize to a stream while we are still
building the object. This sounds possible, although I suspect that the
API would be much more complex.

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

Yes, I believe that, in time, this will solve many scenarios. Definitely
not the DOM-related scenario above, though.

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

Ok, let's just say that I won't use games as a running example until
people start complaining :) However, the DOM situation remains.

Cheers,
 David

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

Received on Friday, 8 March 2013 14:29:33 UTC