On Jun 3, 2010, at 2:42 PM, Oliver Hunt wrote:
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] = ...;
Hack-a-rama! :-P
It still seems to me, whether you use overlayed typed arrays that
users never intentionally use to alias the same given machine-typed
fields, or a "transpose" of such overlayed typed arrays: monotyped
arrays that stride with the right skews to access the members; that we
are just perpetrating the lowest-level hack possible to satisfy the
immediate use-case, without counting usability costs or considering
future-hostility to obvious evolutionary pathways.
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?
If you could say "use a uint32 vector" but every fourth element was
not x, y, or z but rather a quadruple of bytes (rgba), then these
shifts and ORs would be needed. The idea would be to simplify typed
arrays to monotyped, non-aliasing vectors of machine types.
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))
a.x[i] instead of a[i].x doesn't really express this computation, but
never mind. It still seems hard to nest structs or typed arrays in
structs (in typed arrays), or otherwise future-proof this design.
Vlad had WebGL wish-list examples like this:
typedef struct {
float32_t x, y, z;
} vec3_t;
typedef struct {
uint8_t r, g, b, a;
} color_t;
struct {
vec3_t vertex;
vec3_t normal;
color_t color;
} vertex_element_t;
Making people code accesses to such data in some Fortran-ish way is
just awful. I would rather we do something like a subset of Mozilla's
jsctypes, designed by Jason Orendorff, mentioned previously:
https://wiki.mozilla.org/Jsctypes/api#User-defined_types
Some careful thought went into this design. Jason should weigh in here.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
