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: Mike Shaver <mike.shaver@gmail.com>
Date: Fri, 6 Nov 2009 10:13:27 -0500
Message-ID: <cc092ba00911060713l5d402716y1d1e6a19bf7142d4@mail.gmail.com>
To: Breton Slivka <zen@zenpsycho.com>
Cc: P T Withington <ptw@pobox.com>, public-script-coord@w3.org, es-discuss Steen <es-discuss@mozilla.org>
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)

> 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.

Mike
Received on Friday, 6 November 2009 15:14:14 UTC

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