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

Re: [Public WebGL] typed arrays + edge cases



On Wed, Feb 3, 2010 at 2:50 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
>
> A few edge cases keep coming up that are underspecified currently... a few
> of these we talked about in the past, but I don't know if we captured
>
> - If a non-numeric array property is set/read, what happens?
>
> Suggestion: exception (we have out-of-bounds numeric indexes spec'd to raise
> an exception currently, so this falls in the same category to me)

In previous discussions we said that we would delegate the behavior of
the [] ("IndexGetter" / "IndexSetter") operator to the Web IDL spec,
but that calls to the get() / set() methods would raise exceptions. At
the time, Web IDL and the prototype chain of these objects in
ECMAScript would allow out-of-range accesses via the [] operator by
creating new properties against the object. Getting or setting a
non-numeric array property should probably behave the same as for
other JavaScript objects.

> - If the array type is non-float and a non-numeric value is stored, what
> happens?
>
> Suggestion: 0 or exception

This should probably be specified via existing conversions like
ToInt32. As I understand it, this would mean parseInt would return NaN
and ToInt32 would convert this to 0.

> - If the array type is float and a non-numeric value is stored, what
> happens?
>
> Suggestion: NaN or 0 or exception

Would prefer NaN.

> - If the array type is float and someone bit-fiddles an unusual NaN in
> there, does that unusual NaN get passed to the engine to deal with (even if
> it might not normally use them, e.g. signalling NaN etc.)?
>
> Suggestion: I don't have a good one.  The engine should maybe convert all
> NaNs into whatever NaN it understands on element access?

I think this is the best option. Note that when passing the raw data
down to a graphics layer like OpenGL, no such normalization of NaNs
can or should be guaranteed.

-Ken

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

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