[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] Typed Array spec nitpicks
* Please update the date at the top; the spec has evolved quite a bit since the version Vladimir posted to es-discuss but they are dated the same. To a casual visitor, they might appear to be the same at first glance. This doesn't have to be an accurate version/last-edited date, just something newer than 25 January 2010.
* It is unclear if ArrayBuffer data is initialized, i.e. is the output of this defined:
var buf = new ArrayBuffer(1);
var bytes = new Uint8Array(buf);
alert(bytes.get(0)); // shows ... ?
It is obviously a security issue if the buffer exposes uninitialized memory. The spec should indicate how it is initialized.
* The behavior of TypedArray slice() method is undefined if the length ends up being negative. This could presumably raise an exception, clamp the length to 0, or imply support for "inverted" views (which are otherwise disallowed by the TypedArray constructors).
* Possibly not worthwhile to mention in the spec since it's basically Floating Point 101, but writing/reading Floats (single-precision) will in general be "lossy" due to the extension back to double-precision values. For example:
var da = new DataArray(new ArrayBuffer(8));
alert( da.getDouble(0) === 1.2 ); // Probably true
alert( da.getFloat(0) === 1.2 ); // Probably false
The reason to consider calling this out is that it's not an issue in languages like C/C++ where single precision floating point variables and byte-level data access are a given and so you can store/read back a float without loss. Typed Arrays would grant ECMAScript byte-level data access but *not* single precision floating point variables, and that may trip up some developers. (Of course, you should be using an compares-with-epsilon anyway...)
* Really minor: IEEE754 Single- and Double-precision support a variety of NaN values, which are black boxes to ECMAScript (which has NaN and isNaN only). When dealing with externally created data, f = da.getDouble(0); da.setDouble(0, f); may be "lossy". I would expect that most implementations actually would preserve the specific IEEE754 NaN value internally, but the Typed Array spec probably doesn't want to require this.