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

[whatwg] fxCanvas 0.2 and some remarks about canvas spec

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Mon, 15 Nov 2010 20:15:22 -0500
Message-ID: <AANLkTinKnR3vozAJCuTViF513919cTWLdS16fX-NsKkQ@mail.gmail.com>
On Mon, Nov 15, 2010 at 7:46 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> That's evil. ?Isn't JavaScript meant to conceal machine details like
> endianness? ?Couldn't we mandate that the conversion here must be
> little-endian? ?Granted that it'd be slower on ARM and such, but
> "slower" is way better than "causes the program to break". ?If the
> performance is really needed, provide extra methods that convert in
> big-endian fashion. ?Then those writing programs targeted at ARM, or
> those who are willing to write different algorithms for big- and
> little-endian, can use those instead.
>
> Or has this already become such a big and general problem that fixing
> it is basically hopeless, and we're just resigned to everyone's
> scripts breaking on ARM because they were only tested on x86?

(Actually, it seems like ARM can be either little-endian or
big-endian.  Apparently it can vary based on the device, and in some
cases can even be switched on the fly.  So if everyone just hardwires
their ARM smartphones to little-endian, specifying that the function
is little-endian should be even more harmless.  Googling suggests that
at least the iPhone is little-endian.)
Received on Monday, 15 November 2010 17:15:22 UTC

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