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

[whatwg] ArrayBuffer and the structured clone algorithm

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 5 Feb 2011 11:43:06 +1300
Message-ID: <20110204224306.GA14034@wok.mcc.id.au>
Anne van Kesteren:
> > ImageData.data you mean? I wonder if we can still remove
> > CanvasPixelArray.

Tab Atkins Jr.:
> 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.

This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=10930.

Kenneth Russell:
> 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.

So it seems at this stage CanvasPixelArray definitely needs to have the
clamping behaviour.

If people have opinions on whether all JS Number ? IDL integer type
conversions should clamp or wrap, or whether Web IDL should just have an
annotation to indicate what kind of conversion is used, please comment
in the bug.

Thanks,

Cameron

-- 
Cameron McCormack ? http://mcc.id.au/
Received on Friday, 4 February 2011 14:43:06 UTC

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