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

[whatwg] API for encoding/decoding ArrayBuffers into text

From: Brandon Jones <tojiro@gmail.com>
Date: Wed, 14 Mar 2012 08:15:12 -0700
Message-ID: <CAMttkKJ3ea-_tAJkHfXKrDz3WYwpfr_xWEs6EuY1=gfJcDmeXg@mail.gmail.com>
On Wed, Mar 14, 2012 at 1:14 AM, Cedric Vivier <cedricv at neonux.com> wrote:

> What are the 'late' use cases for this?
> The question might sound naive, but to me the encoding/decoding would
> have been really great to have during the time when we didn't have
> support for ArrayBuffers in general input/output APIs like we have now
> (XHR, WebSockets, File API, ...) - which sounds like the mainstream
> use cases to me.

I brought up a use case with Mozilla during their Games Work Week. When
designing formats for games there's a desire to make the content small and
parse fast to keep load times down. When talking about something like a 3D
mesh format, it's very convenient to deliver the mesh to the browser
with responseType = "arraybuffer", as this allows us to push views of the
resulting array directly into WebGL buffers.

There's a lot of content within a model that doesn't cleanly map to a
binary array, however. A good example is if you want to include shader code
as part of the model. It's also very popular currently to use JSON to
describe model metadata. In these cases currently developers have two
choices: embed the string data in the binary buffer, which requires
cumbersome byte-by-byte extraction, or store it in a secondary file that is
requested as string data to begin with. This is the route I've seen taken
most often: Three.js uses it currently, for example. In either case,
however, you are being slowed down by either the string parsing overhead or
the second request.

With the proposed API it would be practical and fast to store string data
and binary mesh data in the same ArrayBuffer, which would be a boon to game
developers seeking to make HTML5 into a first-class gaming platform.

Received on Wednesday, 14 March 2012 08:15:12 UTC

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