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

Re: [Public WebGL] Last-minute comments/questions for 1.0.1 spec/tests





On Wed, Nov 30, 2011 at 10:38 AM, Kenneth Russell <kbr@google.com> wrote:
On Wed, Nov 30, 2011 at 8:52 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
On 28/11/11 08:17 PM, Kenneth Russell wrote:
3. Firefox happens to ensure that identical calls to getUniformLocation
return the _same_ WebGLUniformLocation object, but I don't remember if/where
this is mandated by the spec? And if there is a test for that?


I don't think there is a test for that nor do I think it's in the spec.
Should it be?

It isn't currently in the spec. Similar text could be added as that
for getExtension().

I don't have a strong opinion about whether to make this change at the
current time. It seems minor and that it hasn't impacted application
compatibility. Benoit, if you feel strongly, would you sign up for the
spec change and the addition to the conformance suite?

I don't feel strongly at all about that. On the contrary, if Chrome hasn't been doing this and nobody's every complained about it, it probably means that it's not a useful feature. So we should keep the spec as-is and I'll remove this feature from Firefox which will also simplify code.


WebKit (both Safari and Chrome) hasn't been caching WebGLUniformLocations. No complaints as far as I have heard.

If we are OK with not caching, then we need to mandate not caching in the spec or people will hang expandos on the return value.  This has happened before for other specs and been a real mess to clean up.

This means in particular the following should be false and tested:

context.getUniformLocation(program, "foo") === context.getUniformLocation(program, "foo")
context.getUniformLocation(program, "foo").happy = "lala"; context.getUniformLocation(program, "foo").happy == "lala";

Same goes for any other API that returns a JS object instead of a JS value.

- James


-Ken