[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.

Done.

> * 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.

Specified.

> * 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.

-Ken

-----------------------------------------------------------
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: