[whatwg] Endianness of typed arrays

[Robert O'Callahan]

On Thu, Mar 29, 2012 at 8:08 AM, Kenneth Russell <kbr at google.com> wrote:

> Once DataView is available everywhere then the top priority should be
> to write educational materials regarding binary I/O. It should be
> possible to educate the web development community about correct
> practices with only a few high profile articles.
>

We can give that a try. I would be astounded if it works. Nothing like that
has ever worked before for features I was involved in.

I think we should set some success criteria for that strategy. How about
this: six months after all shipping browers that support typed arrays also
support DataViews, let's evaluate a sample of the very latest applications
using typed arrays to see if they're using DataViews correctly and would
work on big-endian systems. If more than 10% would be broken for
big-endian, we'll declare that strategy to have failed and spec
little-endian. Fair?

Changing the endianness of Uint16Array and the other multi-byte typed
> arrays is not a feasible solution. Existing WebGL programs already
> work correctly on big-endian architectures specifically because the
> typed array views use the host's endianness. If the typed array views
> were changed to be explicitly little-endian, it would be a requirement
> to introduce new big-endian views, and all applications using typed
> arrays would have to be rewritten, not just those which use WebGL.
>

It seems to me that to support little-endian semantics on big-endian
machines, what's needed is to byteswap on JS typed array accesses, and
either to have a modified GL driver that byteswaps before sending data to
the GPU, or preferably to have a GPU that can be switched into
little-endian mode (on a per-context basis, say). None of that seems
technically challenging to me. I imagine that every GPU part will have a
little-endian mode anyway, in order to work with the vast installed base of
little-endian CPUs.

The result
> was increased polymorphism at call sites, which defeated the Java VM's
> optimizing compiler and led to 10x slowdowns in many common
> situations.


I don't see any need for increased polymorphism at call sites in our case.

It is possible to make incorrect assumptions leading to non-portable code,
> but at some level this is possible with nearly any API that extends
> beyond a small, closed world.


Yes, but we work extremely hard in the Web platform to minimize the
possibility.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]