Brendan Eich brendan at
Thu Jun 3 14:19:17 PDT 2010

On Jun 2, 2010, at 4:43 PM, Oliver Hunt wrote:

> I feel this proposal is incredibly complicated for basically the  
> single use case of WebGL.  The majority of use cases for typed  
> arrays are for homogenous element types, and I believe most of what  
> WebGL wants could be achieved simply by use of homogeneously typed  
> arrays that were stepped in a way to avoid aliasing (this would not  
> be complicated from either implementation or specification PoV).   
> The usability would likely be better than the current webgl model,  
> it wouldn't require aliasing, and it would require such a  
> complicated addition to the language.

It would help for the WebGL use case to be simplified to unify typed  
arrays and array buffers, eliminating aliasing and requiring monotyped  

But IIRC WebGL folks other than yourself (who should please speak  
up ;-) can't take the hit of, e.g. (r << 24) | (g << 16) | (b << 8) |  
a and then a 32-bit store via assignment to the "rgba" element of what  
is ideally a typed array of {x, y, z: uint32; r, g, b, a: uint8}  
structs (to abuse syntax further), but which per your suggestion above  
would have to be a uint32 array with x, y, z, and rgba elements stored  
in sequence.

A sufficiently optimizin JS VM could perhaps recognize all those  
shifts and ORs and issue byte stores instead. I'm assuming issuing the  
narrower stores beats all the shifty ALU ops and then one 32-bit store.

This could all be "optimization", an implementation issue. Except  
WebGL needs speed, and this need is evident in the semantics of  
proposals such as typed arrays.

Ignoring all such optimization guarantees, the shift and OR code is  
ugly and verbose. So there's a usability argument to be made for  
arrays of structs, if not typed arrays as proposed.

As your amusing ES5 metaprogramming code shows, we could support  
arrays of structs using objects, and leave optimization out of the  
spec. In doing this we'd be preserving the "b = a[i]; b.x = 42;  
assert(a[i].x === 42)" behavior.

We would break "a[j] = a[i]; a[j].x = 42; assert(a[i].x === 42)" for  
j != i and j < a.length. But perhaps that is not a useful equivalence.  
Or we could require an explicit copy operation to assign from a[i] to  
a[j], or throw an error (but the last seems gratuitous since one can  
introduce a temporary b as workaround).

Implicit struct copy seems worse than reified object as fat-pointer.  
Implicit copying could be quite expensive, even if optimized away for  
"a[i].x" but not "b = a[i]".

Bottom line: it still seems to me that the WebGL use-case is C-like  
(GL was a C API back in the day), and wants arrays (C vectors) of  
structs that are allocated in-line and packed full of machine types,  
and possibly even sub-structs or sub-typed-arrays. Vlad averred as  
much recently.

The current typed array views into array buffers, besides reminding  
Tucker of Common Lisp "displaced arrays", smell of Fortran common  
blocks holding overlayed vectors. Surely we can do better!


More information about the es-discuss mailing list