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

Re: [Public WebGL] Web Workers and ArrayBuffers?



On Tue, Apr 12, 2011 at 10:15 AM, Oliver Hunt <oliver@apple.com> wrote:
> I am still concerned about the semantics of the zero copy idea - where is this postMessage behaviour defined?

It hasn't been written down formally yet; the initial idea was
hammered out during a couple of meetings between Mozilla and Google.
The basic idea is that if an ArrayBuffer is sent via structured clone,
the instance on the current thread is "closed", meaning that it, and
all views on to it, immediately become zero-length. If a typed array
view is sent via structured clone, then it, its backing ArrayBuffer,
and any other views on to the ArrayBuffer are closed.

Sending an object graph which references multiple views, all
referencing the same ArrayBuffer, must work; the ArrayBuffer is
reconstituted on the other side, along with all of the referenced
views.

Expect a strawman draft in the typed array spec's editor's draft
within a couple of weeks.

-Ken

> --Oliver
>
> On Apr 12, 2011, at 10:07 AM, Kenneth Russell 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.
>>
>> -Ken
>>
>> 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 ?
>>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>
>
>
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------