On Jun 3, 2010, at 2:19 PM, Brendan Eich wrote: > 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 arrays. > > 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.
My proposal would have you do something along the lines of: buffer = new ArrayBuffer({x, y, z: uint32; r, g, b, a: uint8} ) // using your abused syntax producing an object where you would do: buffer.x[i] = ...; buffer.y[i] = ...; ... buffer.r[i] = ...; buffer.g[i] = ...; etc > 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. I'm not sure where this shift/or stuff comes from? > > 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! My intention was that you end up with a "struct of arrays" rather than an "array of structs" -- internally the implementation would be using flat storage in the form requested. The exposed accessor for a given field array would be something akin to return toJSValue(*(MachineType*)(data + index * structSize + fieldOffset)) --Oliver _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss