[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Re: Question about Strings from TypedArrays

On Tue, Feb 15, 2011 at 4:31 PM, Jeff Schiller <jeffschiller@google.com> 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 alone)

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