W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

[whatwg] Endianness of typed arrays

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 28 Mar 2012 18:30:19 -0500
Message-ID: <CABirCh-9uU2jxmvf2jQoJDJ4Bu3iGEZZAgpZSsU65D9XS1YPbg@mail.gmail.com>
On Wed, Mar 28, 2012 at 2:08 PM, Kenneth Russell <kbr at google.com> wrote:

> The top priority should be to implement DataView universally.
>

DataView isn't relevant to the discussion.  People are using
ArrayBufferViews in ways that assume little-endian access, and that isn't
going to go away.  If any production browser is ever released on a
production big-endian system, it'll expose ArrayBuffers as little-endian,
even if that causes performance problems with WebGL, because it will
minimize the amount of breakage.

It's also unreasonable to expect web developers to go to extra effort for
big-endian systems (eg. by serving different, big-endian resources from
XHR).  You're expecting every developer using ArrayBuffer to jump hoops,
adding significant complexity and testing requirements, in order to support
an optimization on systems with essentially zero market share.  I'm
certainly not going to do that, and I doubt many other web developers will,
either; big endian systems aren't worth our time.

And for all realistic purposes, the world has standardized on
little-endian.  If people choose to develop a big-endian system today, the
challenges of doing so are their problem.  Just as new APIs (such as
WebSockets and Server-Sent Events) no longer spend time supporting legacy
encodings, simplifying everyone's life by only supporting UTF-8, new APIs
should stop pretending big endian is important and optimize for
little-endian.

All that said, to partially sidestep the issue, I'd propose adding
separate, explicitly big-endian and little-endian view types for each view
type.  That is,

Int16LEArray, Uint16LEArray
Int32LEArray, Uint32LEArray
Float32LEArray, Float64LEArray
Int16BEArray, Uint16BEArray
Int32BEArray, Uint32BEArray
Float32BEArray, Float32LEArray,
Float64BEArray, Float64LEArray

I think adding these is a no-brainer, since it's trivial and obviously
useful, and lets us at least pretend the issue doesn't exist...

On Wed, Mar 28, 2012 at 4:27 PM, Brandon Jones <tojiro at gmail.com> wrote:

> So the question is: What exactly are we expecting that "magic" to be? We
> can't just swizzle every 4 bytes. Either the graphics driver must do the
> endian swap as it processes the buffer, which is possible but entirely out
> of the browsers control,


Please see Benoit's mail, for at least one possible approach.  It's hard to
do, and harder to do efficiently, but if you're creating a platform with
unusual endianness, it's you that needs to jump the hoops to make it work,
not every web developer in the world.

-- 
Glenn Maynard
Received on Wednesday, 28 March 2012 16:30:19 UTC

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