[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Web Workers and ArrayBuffers?

Using Chrome 10.0.648.204
This actually already works well on Firefox. the typed array are preserved in the received object.
So I only need to add a check for Chrome.
There's this bug report about it -

Why is there a need for a revision to the typed array spec? (not that it really bothers me)

Another note - Firefox also seems to be stricter about which objects it agrees to post . If the posted object contain functions, an exception is thrown. The same postMessage goes through without error in Chrome. Not sure if that's a bug or a feature.

On 12 April 2011 20:07, Kenneth Russell <kbr@google.com> wrote:
What browser and version are you using?

We are about to start revising the Typed Array specification to define
the behavior of passing ArrayBuffers and typed array views between the
main thread and worker threads. The new behavior will be zero-copy,
and if you ping-pong the ArrayBuffers back and forth, you'll be able
to implement really efficient producer-consumer queues.

These changes will be discussed on this list as they show up, and
hopefully you'll see this behavior start to appear in nightly builds
of browsers within a couple of months.


On Tue, Apr 12, 2011 at 4:41 AM, Shy Shalom <shooshx@gmail.com> wrote:
> I'm trying to write a Worker thread that does some processing and creates a
> mesh on the fly.
> It works fine up until returning the created result to the main GUI thread.
> it seems that the communication between the worker and the main thread does
> JSON serialization,
> so if I'm sending a Float32Array from the worker, what I get in the main
> thread is a regular _javascript_ array.
> A trivial solution is to just rebuild the Float32Array again from the array
> I receive but that seems wasteful.
> Is there a good workaround for this? Maybe a way to tell the JSON
> deserialization that something should be a Float32Array ?