W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] ArrayBuffer and the structured clone algorithm

From: Kenneth Russell <kbr@google.com>
Date: Tue, 1 Feb 2011 11:13:54 -0800
Message-ID: <AANLkTi=W7qKL2DUBT24t5ZNR5RqX-bxi1YuDwt++BLxn@mail.gmail.com>
On Tue, Feb 1, 2011 at 11:08 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, Feb 1, 2011 at 10:04 AM, Anne van Kesteren <annevk at opera.com> wrote:
>> On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>>
>>> On 2/1/11 5:19 AM, Simon Pieters wrote:
>>>>
>>>> While you're discussing efficient handoff of ArrayBuffer, do you also
>>>> keep in mind efficient handoff of other objects (e.g. ImageData) as
>>>> discussed in this thread?:
>>>>
>>>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029885.html
>>>
>>> For what it's worth, in Gecko that's the same thing, since imagedata is
>>> just a typed array in our implementation.
>>
>> ImageData.data you mean? I wonder if we can still remove CanvasPixelArray.
>
> Only if the out-of-bounds behavior for entries in Typed Arrays matches
> the current clamping behavior for CanvasPixelArray. ?I don't see any
> explicit indication of what should be done in the Typed Array spec,
> which I suppose means that they're relying on WebIDL's coercion algos
> to keep things in-range for the given view. ?WebIDL has the wrong
> behavior here right now (it wraps), though I think heycan is receptive
> to changing it.

For this reason I think we need to keep CanvasPixelArray distinct. I
certainly hope that Web IDL does not change its conversion rules to
mimic the clamping behavior in CanvasPixelArray. Right now Web IDL
delegates to the ECMA-262 specification for primitive conversions,
which have the wrapping behavior of C-style casts rather than clamping
behavior. Forcing clamping for out-of-range integer values would
impose a significant negative performance constraint on typed arrays.

-Ken
Received on Tuesday, 1 February 2011 11:13:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC