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

Re: [Public WebGL] typed arrays + edge cases

(sorry I couldn't make the call this morning -- still getting over whatever has a deathgrip on me)

On 2/4/2010 8:43 AM, Oliver Hunt wrote:
On Feb 3, 2010, at 9:41 PM, Vladimir Vukicevic wrote:

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.
i don't buy this at all -- they _are_ an object -- in a js binding typeof will produce "object".... I suppose it would be conceivable that we could make the object inextensible (per es5 semantics) but i don't really see what that buys us, CanvasPixelArray in webkit is internally implemented as a ByteArray but is still an object and can be treated as such, and I don't see anything that making it inextensible would give us that could improve performance...

Well, like I said, it buys us the ability to more efficiently reason about the object. For our implementation at least, it's a big performance boost if for each access, we know ahead of time what the type will be. It lets us generate much more efficient code, without inserting tests and branches along the way. In addition, making these inextensible makes it easier for developers to track down wrong behaviour, such as out of bounds access. The focus of these types is native type interoperability and performance; I don't think we should ignore any potential performance boost, especially when it's one that only affects the form some code takes, rather than making it possible/impossible to do something.

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