W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 06 Nov 2009 09:34:10 -0800
Cc: Breton Slivka <zen@zenpsycho.com>, P T Withington <ptw@pobox.com>, public-script-coord@w3.org, es-discuss Steen <es-discuss@mozilla.org>
Message-id: <99AF56A8-8221-42A3-84AF-5515DE28F4D5@apple.com>
To: Mike Shaver <mike.shaver@gmail.com>

On Nov 6, 2009, at 7:13 AM, Mike Shaver wrote:

> On Fri, Nov 6, 2009 at 9:31 AM, Breton Slivka <zen@zenpsycho.com>  
> wrote:
>> I think the C language has
>> possibly biased us into thinking of data as a sequence of 8-bit  
>> bytes,
>> when that is just what happened to be convenient for C.
>
> For types called ByteArray and ByteVector, I think a byte orientation
> is appropriate.  Doing things other than bytes brings endianness into
> play (ask the WebGL guys, if you know any)

At some point, if we want to make it easy and efficient for ECMAScript  
to do something like decode a GIF, we may want to provide facilities  
for converting between host and network byte order. My recommendation  
would be to leave that out of the v1 API though.

>
>> My question is (since nobody seems to have brought it up yet) is how
>> does this proposal fit into the html5 canvas data api? (not the data
>> URI api).
>
> I would expect that there would be some harmonization desired there,  
> but:
>
>> If you call canvascontext.getImageData(0,0,width,height), you get an
>> object with some mutable properties, and a data property holding what
>> looks like an array of numbers between 0 and 255. The data property
>> supposedly has an efficient implementation.
>
> Using that data property may be more efficient than using an Array,
> but that depends a bunch on the implementation choices for the JS
> engine and Canvas implementation.
>
> It was also proposed, though I don't know if it is generally accepted,
> that the Canvas Data object clamp its values to 255 on set, so if
> people feel that's a necessary behaviour (I personally don't, but my
> opinion carries less than the mean weight in these discussions) then
> ByteArray might not be suitable.
>
> The Canvas Data object is also sort of half-mutable: you can change
> the values of the data elements, but can't change the size of the
> "array".  That could turn out to be a useful property for optimized
> access to it, since you can amortize length checks quite well.

CanvasPixelArray seems close enough to a mutable general-purpose  
binary data container that maybe it's worth considering whether to  
specifically serve this case (fixed length, mutable contents) at the  
ECMAScript level. It would then likely be possible to change  
CanvasPixelArray to inherit from a general-purpose binary data  
container without breaking compat.

Regards,
Maciej
Received on Friday, 6 November 2009 17:34:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC