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 01:19:12 -0500
Message-ID: <4CE0D0E0.6000801@mit.edu>
On 11/14/10 3:44 AM, Evgeny Burzak wrote:
> Yes, this is local problem for canvas emulator and IE.
> So which format should I use? A lot of people using WinXP and IE 6-8 at this moment. There are no typed arrays, no fast JS and so on... :(

Sounds like you don't really have a choice, right?  ;)

That said, are you providing an API that you then need to map to the 
normal canvas API in non-IE browsers?  Is that the sticking point?

> So while is it possible to add conversion methods to the typed array?
> Something like fromArray32() and fromArray8() ?

Um... You can already do that with WebGL typed arrays.  That is, you can 
cast a Uint32Array to a Uint8Array, effectively.  Each typed array has a 
.buffer property that hands back an object representing the underlying 
memory.  Then you can pass that as an argument to a typed array 
constructor to create a new array referencing the same underlying memory.

Note that there are two giant caveats here:

1)  While in Gecko it's the case that canvas imagedata plays nice
     with WebGL typed arrays, that's not the case in Webkit or
     Presto last I checked.
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.

Of course you could detect endianness and change how you construct your 
integers to work around caveat #2....

-Boris
Received on Sunday, 14 November 2010 22:19:12 UTC

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