[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Explicit unboxing for object identifiers
On Sun, Jan 8, 2012 at 9:19 PM, Benoit Jacob <firstname.lastname@example.org>
On Sun, Jan 8, 2012 at 11:37 AM, Benoit Jacob <email@example.com>
In Firefox <= 10, equal uniform locations give the same WebGLUniformLocation object, so the location1 === location2 test just works.
We just changed this for Firefox 11 as (per a mailing list discussion) there was agreement that this wasn't needed, and so the extra code in Gecko needed to make that work was seen as unneeded complexity.
What is you use case for comparing uniform locations? Why can't you implement it on your side, maybe with a shim/wrapper around webgl.getUniformLocation?
Hrrm, does this mean that:
gl.getUniformLocation(prog, "foo") != gl.getUniformLocation(prog, "foo")
? That seems really unexpected and very likely to cause hard to untable confusion and bugs. Hashtable (object property) storage especially using uniform locations as keys doesn't seem that unexpected, for example to store the current value or somesuch for optimization purpose.
A developer or a library can't just wrap getUniformLocation -- they'd have to track all shaders attached to 'prog', track compilation and linking, etc., because any of those could cause the return value to actually -need- to change. It seems very tricky to get right in a wrapper, and I don't see any reason to dump this complexity on wrappers when a simple hashtable would do it on the implementation side.
Good points, so we can consider adding the same-uniformlocation-object requirement to the spec after 1.0.1 (it seems too late for 1.0.1)?
Yep, I'd suggest this... it seems like a relatively low impact (implementation-wise) change, other than preserving user-set properties on the objects you mention below -- which should hopefully be not too bad?
- this never was required by the spec and I don't believe that any other browser than Firefox did that
Ah, didn't realize that other implementations didn't.
- although Firefox <= 10 did that, it never preserved added attributes on such objects, as for example Rehno asked for in this thread (in the way that added attributes are required to be preserved on the objects returned by getExtension, for example).
Yeah, this was definitely an issue. The workaround was to use a hashtable for properties :) But it's definitely something that should be fixed, if webgl starts guaranteeing object identity.