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

Re: [Public WebGL] typed arrays + edge cases

On 2/3/2010 7:04 PM, Chris Marrin wrote:
On Feb 3, 2010, at 2:50 PM, Vladimir Vukicevic 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)
I'd really like this to work. It enables using arrays to store additional, application specific data, just like normal Arrays.

Mm.. I'd actually like to discourage this since it makes it much harder to reason about these objects. It's a pretty big win for perf (at least for us) if it's possible to say "property access on this object will always return type X or will throw an exception". For storing additional properties, I think that { data: Uint8Array(...), otherProp: false, someOtherProp: true } is just as easy, and not allowing them on the typed arrays really reinforces that it's not a generic object, and I don't think they should be treated as such.

- 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 all invalid NaN variants should be converted to a quiet NaN, which is what JS supports, right? I think the values we should support are all valid, normalized floats, +/-Inf and a quiet NaN. Everything should be converted to a quiet NaN

That sounds fine to me. The conversion should happen at read time (array element access time), right?

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