On Fri, Jun 24, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 24, 2011 at 3:43 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 24 Jun 2011, Kenneth Russell wrote:
Slightly larger issue. In the typed array spec, views like Float32Array
refer to an ArrayBuffer instance. It's
On Thu, Jun 23, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 21 Jun 2011, Ian Hickson wrote:
How about we just make postMessage() take the object to clone in the first
argument, an array of objects to transfer in the second; on the other
side, the author receives the object
On Fri, 24 Jun 2011, Kenneth Russell wrote:
Slightly larger issue. In the typed array spec, views like Float32Array
refer to an ArrayBuffer instance. It's desired to be able to transfer
multiple views of the same ArrayBuffer in the same postMessage call.
Currently, because each
On Tue, 21 Jun 2011, Ian Hickson wrote:
How about we just make postMessage() take the object to clone in the first
argument, an array of objects to transfer in the second; on the other
side, the author receives the object cloned, with anything listed in the
array and in the structured
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's say the call doesn't throw when given a type B that isn't
transferrable.
Let's also say some later changes the javascript code and uses B after the
postMessage call.
Everything work. No throw is done and B isn't
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's say the call doesn't throw when given a type B that isn't
transferrable.
Let's also say some later changes the javascript code and uses B after
On Wed, Jun 22, 2011 at 3:14 AM, David Levin le...@chromium.org wrote:
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's say the call doesn't throw when given a type B that isn't
transferrable.
On Wed, Jun 22, 2011 at 12:26 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 3:14 AM, David Levin le...@chromium.org wrote:
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's
On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org wrote:
Making people use a helper function like that is just making them jump an
unnecessary hoop.
It makes them jump through another hoop to potentially misuse the api.
No, it's another hoop that *everyone* has to jump
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org wrote:
Making people use a helper function like that is just making them jump an
unnecessary hoop.
It makes them jump through another hoop to potentially
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org wrote:
Making people use a helper function like that is just making them jump an
unnecessary hoop.
It makes them jump through another hoop to potentially
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 1:57 AM, David Levin le...@chromium.org wrote:
Let's say the call doesn't throw when given a type B that isn't
transferrable.
Let's also say some later changes the javascript code and uses B after
On Mon, 20 Jun 2011, Jonas Sicking wrote:
If data appears both in the .ports array and the .data property, then
people will be tempted to create protocols which only work if the array
buffer is transferred, i.e. if the receiver only looks in .ports. I.e.
people will likely end up with
On Tue, Jun 21, 2011 at 12:39 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 20 Jun 2011, Jonas Sicking wrote:
If data appears both in the .ports array and the .data property, then
people will be tempted to create protocols which only work if the array
buffer is transferred, i.e. if the
On Tue, Jun 21, 2011 at 11:07 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 21 Jun 2011, Jonas Sicking wrote:
On Tue, Jun 21, 2011 at 12:39 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 20 Jun 2011, Jonas Sicking wrote:
If data appears both in the .ports array and the .data property, then
What happens if an object is included in the second list that doesn't
support transfer? Ian said that it would throw, but I'm not sure that's
best.
Suppose Firefox N supports transferring ArrayBuffer, and Firefox N+1 adds
support for transferring ImageData. Developers working with Firefox N+1
On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard gl...@zewt.org wrote:
What happens if an object is included in the second list that doesn't
support transfer? Ian said that it would throw, but I'm not sure that's
best.
If it doesn't throw, doesn't that introduce the backwards compat issue
On Wed, Jun 22, 2011 at 1:25 AM, David Levin le...@chromium.org wrote:
On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard gl...@zewt.org wrote:
What happens if an object is included in the second list that doesn't
support transfer? Ian said that it would throw, but I'm not sure that's
best.
On Tue, Jun 21, 2011 at 10:48 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jun 22, 2011 at 1:25 AM, David Levin le...@chromium.org wrote:
On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard gl...@zewt.org wrote:
What happens if an object is included in the second list that doesn't
support
So the proposal that seems to address the most concerns raised in this
thread would be to have postMessage() work like this:
postMessage({ object }, [ array ]);
...with it resulting in an event that contains both {object} and [array],
where everything in the array is transferred, and
On Jun/8/2011 5:24 PM, ext Kenneth Russell wrote:
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
- Maintain 100% backward compatibility
- Enhance the ability to pass
From: Arthur Barstow [mailto:art.bars...@nokia.com]
On Jun/8/2011 5:24 PM, ext Kenneth Russell wrote:
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
- Maintain 100% backward
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12947
-Original Message-
From: Travis Leithead
Sent: Monday, June 13, 2011 10:49 AM
To: Arthur Barstow
Cc: Andrew Wilson; Glenn Maynard; Jonas Sicking; Dmitry Lomov; David Levin; ben
turner; public-webapps@w3.org; Ian Hickson; ext
On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Honestly, there’s something about this whole discussion that just doesn’t
feel right.
I looks like we’re trying to graft-in this new concept of transfer of
ownership into the existing postMessage semantics
(Can you please reset your font?)
On Fri, Jun 10, 2011 at 1:54 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
We don’t really need to support JavaScript objects, arrays, complex
graphs, etc. at all with the new API
Strongly disagree. I should be able to transfer objects
From: Kenneth Russell [mailto:k...@google.com], Sent: Thursday, June 09, 2011
11:15 PM
On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Honestly, there's something about this whole discussion that just
doesn't feel right.
I looks like we're trying to
On Fri, Jun 10, 2011 at 12:50 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
From: Kenneth Russell [mailto:k...@google.com], Sent: Thursday, June 09,
2011 11:15 PM
On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Honestly, there's something
On Fri, 10 Jun 2011, Travis Leithead wrote:
This looks like a mis-reading on my part of step 2 of the postMessage
algorithm:
2.If the method was called with a second argument ports and that
argument isn't null, then, if any of the entries in ports are null, if
any MessagePort object is
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell k...@google.com wrote:
Thinking about this more, that port could be sent as the data
attribute of the event instead of the empty string. Then the ports
attribute on MessageEvent could be safely deprecated.
-Ken
So a number of different
On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson atwil...@google.com wrote:
1) I'm not completely sure I understand what the new postMessage()
semantics
look like. Since cloning a port is a destructive operation, I like the
fact
that the current postMessage() API requires the developer to
On Thu, Jun 9, 2011 at 11:13 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson atwil...@google.com wrote:
1) I'm not completely sure I understand what the new postMessage()
semantics
look like. Since cloning a port is a destructive operation, I like the
From: Andrew Wilson [mailto:atwil...@google.com]
Sent: Friday, June 03, 2011 2:15 PM
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell
k...@google.commailto:k...@google.com wrote:
On Fri, Jun 3, 2011 at
Honestly, there's something about this whole discussion that just doesn't feel
right.
I looks like we're trying to graft-in this new concept of transfer of ownership
into the existing postMessage semantics (i.e., object cloning). Any way I try
to make it work, it just looks like peaches
Now that the responses on this thread have slowed, I would appreciate if
the participants would please summarize where they think we are on this
issue, e.g. the points of agreement and disagreement, how to move
forward, etc.
Also, coming back to the question in the subject (and I apologize if
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
- Maintain 100% backward compatibility
- Enhance the ability to pass MessagePorts, so that the object graph
can refer to them as
On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell k...@google.com wrote:
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
Array or object? (by object I mean: {transfer:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
-Ken
On Wed, Jun 8, 2011 at 2:29 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell
I agree with Kenneth.
-Ben Turner
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
-Ken
On Wed, Jun 8, 2011 at
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific
ok.
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
On Wed, Jun 8, 2011 at 5:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
Possibly, but it makes the design of this modification cleaner.
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better
On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer
On Wed, Jun 8, 2011 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote:
This all sounds great to me, but I think we should additionally make
the 'ports' attribute on the MessageEvent interface deprecated.
The only use case for it is to support existing code which doesn't
pass ports in the
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed,
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 4:41 PM, David Levin le...@chromium.org wrote:
None of the objects which allow transferring of ownership has children
so this doesn't appear to be a problem at this time. If it indeed does
turn
On Fri, Jun 3, 2011 at 2:44 AM, Dmitry Lomov dslo...@chromium.org wrote:
Now show me the code needed to send a message which contains one big
buffer from you that you want to transfer, along with some data that
you got from some other piece of code and which you do not want to
modify and which
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 4:41 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 11:44 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 4:41 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer lists are transferred, others are cloned.
This again causes the
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
to appear in transfer lists. ArrayBuffers that are under objects in
transfer
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com wrote:
a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
to
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
wrote:
a)
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On
On Fri, Jun 3, 2011 at 2:25 PM, Dmitry Lomov dslo...@google.com wrote:
(I am answering on multiple points - I do not want to fork the thread)
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri,
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On
On Fri, Jun 3, 2011 at 2:54 PM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com wrote:
significant motivation. The stated motivations for breaking this API don't
seem compelling to me given the existence of backwards-compatible
alternatives.
This proposal is backwards-compatible. If the argument is an
On Fri, Jun 3, 2011 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:
e) Keep MessagePort[] ports the way it is but deprecate it.
For anyone not looking closely at the IDL while reading this, this
means deprecating (for whatever value deprecate has on the web) the
ports array in
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com wrote:
significant motivation. The stated motivations for breaking this API
don't
seem compelling to me given the existence of backwards-compatible
On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson atwil...@google.com wrote:
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com wrote:
significant motivation. The stated motivations for breaking this API
don't
What are the specific change(s) to the Web Messaging spec being proposed:
http://dev.w3.org/html5/postmsg/
-AB
On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote:
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russellk...@google.com wrote:
On Tue, May 31, 2011 at 3:35 PM, Ian Hicksoni...@hixie.ch
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really any special custom behavior for postMessage)
to 1) participate in the special inheritance interface and 2) be isolated from
the
(It would have been better not to fork the thread with a different
subject line...)
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really
any special custom behavior for postMessage) to 1) participate in the special
inheritance
interface and 2) be
On Thu, Jun 2, 2011 at 12:58 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm a little concerned about the inherit approach that Ian outlines...
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really any special custom behavior for
On Thu, Jun 2, 2011 at 10:22 AM, ben turner bent.mozi...@gmail.com wrote:
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
This plan requires all objects that want to opt-in to a new
transfer-of-ownership (or really
any special custom behavior for
On Thu, 2 Jun 2011, ben turner wrote:
I interpreted the proposal differently... This is what I envisioned:
var bufferToTransfer = /* make ArrayBuffer */;
var bufferToCopy = /* make ArrayBuffer */;
var worker = /* make Worker */;
var message = { buf1: bufferToTransfer, buf2:
On Thu, Jun 2, 2011 at 11:54 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 Jun 2011, ben turner wrote:
I interpreted the proposal differently... This is what I envisioned:
var bufferToTransfer = /* make ArrayBuffer */;
var bufferToCopy = /* make ArrayBuffer */;
var worker = /* make
In summary, there is a desire for a mechanism to transfer objects (to allow
for potentially better perf) across a MessagePort.
The mechanism:
- needs to have an intuitive feel for developers,
- must preserve backwards compatibility,
- should ideally allow the port to function the same
On 6/2/11 3:53 PM, David Levin wrote:
The mechanism:
* needs to have an intuitive feel for developers,
* must preserve backwards compatibility,
* should ideally allow the port to function the same regardless of
whether the message was cloned or transferred.
I'm not sure what
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
In summary, there is a desire for a mechanism to transfer objects (to allow
for potentially better perf) across a MessagePort.
The mechanism:
needs to have an intuitive feel for developers,
must preserve backwards
On Thu, Jun 2, 2011 at 1:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/2/11 3:53 PM, David Levin wrote:
The mechanism:
* needs to have an intuitive feel for developers,
* must preserve backwards compatibility,
* should ideally allow the port to function the same regardless of
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell k...@google.com wrote:
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
The desire would be for this change to apply not just to the
postMessage method on MessagePort and Worker but also to that on
Window.
I agree--the
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell k...@google.com wrote:
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
The desire would be for this change to apply not just to the
postMessage method
On Thu, Jun 2, 2011 at 5:01 PM, David Levin le...@chromium.org wrote:
It feels like this array of objects given to transfer may complicate (and
slow down) both the implementation of this as well as the developer's use of
it.
Even with thousands of objects, creating an array containing them is
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell k...@google.com wrote:
On Thu, Jun 2, 2011 at 12:53 PM, David Levin le...@chromium.org wrote:
The
On Thu, Jun 2, 2011 at 5:30 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jun 2, 2011 at 5:01 PM, David Levin le...@chromium.org wrote:
It feels like this array of objects given to transfer may complicate (and
slow down) both the implementation of this as well as the developer's use of
it.
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 2, 2011 at 2:01 PM, David Levin le...@chromium.org wrote:
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard gl...@zewt.org wrote:
port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
[port]});
79 matches
Mail list logo
