W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] fxCanvas 0.2 and some remarks about canvas spec

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 15 Nov 2010 21:34:36 -0500
Message-ID: <4CE1EDBC.3050906@mit.edu>
On 11/15/10 7:46 PM, Aryeh Gregor wrote:
> On Mon, Nov 15, 2010 at 1:19 AM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>> 2)  Casting an array of integers to an array of bytes will give you
>>     different results on different hardware.  For example, the
>>     integer 0xffff0080 when viewed as imagedata bytes is either
>>     rgba(255, 255, 0, 0.5) (half-opaque yellow) or rgba(128, 0, 255, 1)
>>     (fully opaque purplish blue), depending on your endianness.
>
> That's evil.

It's compatible with how GL works, though, as I understand.

> Isn't JavaScript meant to conceal machine details like
> endianness?

Well, usually yes.  ;)

> Couldn't we mandate that the conversion here must be
> little-endian?

What does that mean in practice?  That every non-byte read from a typed 
array needs to swap byte order as needed?  I guess that's doable; mail 
the authors of 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html 
?

>  Granted that it'd be slower on ARM and such

Only some ARM.  Other ARM is little-endian.  It depends on the 
motherboard, and on some ARM devices may be a boot-time option, as I 
understand.

> Or has this already become such a big and general problem

It's only a problem for this particular API which is all about raw 
memory access.  I mean... this is an API that lets you take an array of 
doubles and then examine the bytes.

-Boris
Received on Monday, 15 November 2010 18:34:36 UTC

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