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

Re: [Public WebGL] Typed Array spec nitpicks

I apologize for the long delay in replying. Please see my other post
to the list regarding recent changes made.

On Mon, Apr 12, 2010 at 12:02 PM, Joshua Bell <josh@lindenlab.com> wrote:
> For experimental purposes unrelated to WebGL, I
> implemented https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html as
> closely as I could in ECMAScript 3, and observed a few issues:
> * 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).

Specified as clamping the length to 0.

> * 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));
> da.setDouble(0, 1.2);
> alert( da.getDouble(0) === 1.2 ); // Probably true
> da.setFloat(0, 1.2);
> 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.

I've left this untouched for the moment. We still need to clarify the
conversions that occur during stores.


You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: