[Public WebGL] Re: Question about Strings from TypedArrays

Joshua Bell [email protected]
Wed Feb 16 10:03:27 PST 2011

On Tue, Feb 15, 2011 at 4:31 PM, Jeff Schiller <[email protected]>wrote:

> I'd like to resurrect the discussions around conversion of Strings from/to
> TypedArrays [1].  I take it from internal discussions with Kenneth that
> nothing has happened yet on this front.  Caveat upfront: I am not a browser
> developer, I'm a front-end web developer.

And apologies for instigating some of the previous discussions but not
pursuing it further. Despite personal interest, I haven't had a strong
business need that's been pushing for a high-performance solution here.

> I found out the following hack works in Firefox 4:


> But this doesn't work in Chrome, unfortunately.  I'm not sure which browser
> is following the letter of the ECMAScript spec there.

Per my reading of ES-262 5th ed, this should also work:

String.fromCharCode.apply(null, {length:3, 0: 65, 1: 66, 2: 67})

Function.prototype.apply ( does not require that the type of the
second argument be anything other than an object with a Uint32-looking
length property. A Typed Array would satisfy this requirement. It appears
that the browsers on my boxes other than Firefox 4 are requiring that it be
an actual JS Array. So... I'd say this is a Chrome bug (but Chrome is not

What do you folks think of something as straightforward as this:
>   String.fromTypedArray(aTypedArray, "utf-8");

To make the ECMAScript folks happy, I'd drop the dependencies on Typed Array
here, since it's unnecessary. You just need an array-like object (which
typed arrays satisfy, but so do JS arrays and specially-crafted objects).

(I'm thinking that avoiding this dependency is desirable e.g. to allow
"polyfill" implementations for non-WebGL-supporting browsers, but I may be
alone in this desire.)

The API could then be as simple as:

var s = String.decode(arraylike, encoding);

... with, as you suggest, specific exceptions thrown if the encoding is
unknown or if the data is invalid (including non-octet values produced by
iterating over the arraylike object).

which would return a JavaScript string with exceptions being thrown for
> invalid encodings, etc.  For the reverse conversion we could add another
> constructor that takes a string and an encoding in.

The reverse is trickier if we want to avoid a dependency on Typed Arrays, if
the API produces a new array.

var what_type_here = String.prototype.encode(encoding); // ???
String.prototype.encode(encoding, arraylike[, offset]); // ???

The latter would be type-agnostic, but is since the encoded length isn't
known in advance allocating a typed array would require trial and error (or
an additional API).

In a follow-up to

> [1]
> https://www.khronos.org/webgl/public-mailing-list/archives/1006/msg00191.html

... I pointed at the CommonJS proposals, which would be worth inspecting for
API patterns to follow.

-- Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110216/876077d0/attachment.html>

More information about the public_webgl mailing list