[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




I've checked in a few changes to the conformance tests, including what we discussed on this list and a couple more.


Benoit



r16232 | bjacob | 2011-12-02 21:09:27 -0500 (Fri, 02 Dec 2011) | 3 lines
Changed paths:
M /registry/trunk/public/webgl/sdk/tests/conformance/uniforms/uniform-location.html


Testing that getUniformLocation returns a different object everytime


------------------------------------------------------------------------
r16233 | bjacob | 2011-12-02 21:33:47 -0500 (Fri, 02 Dec 2011) | 3 lines
Changed paths:
M /registry/trunk/public/webgl/sdk/tests/conformance/misc/object-deletion-behaviour.html


test that deleting a buffer unbinds it from any vertex attrib that was using it


------------------------------------------------------------------------
r16234 | bjacob | 2011-12-02 21:38:37 -0500 (Fri, 02 Dec 2011) | 4 lines
Changed paths:
M /registry/trunk/public/webgl/sdk/tests/conformance/misc/object-deletion-behaviour.html


test deletion of a buffer that wasn't currently bound.
that didn't seem to be covered by the test.


------------------------------------------------------------------------
r16235 | bjacob | 2011-12-02 21:48:02 -0500 (Fri, 02 Dec 2011) | 3 lines
Changed paths:
M /registry/trunk/public/webgl/sdk/tests/conformance/misc/object-deletion-behaviour.html


test that deleting a texture unbinds it from other texture units as well


------------------------------------------------------------------------
r16236 | bjacob | 2011-12-02 22:09:02 -0500 (Fri, 02 Dec 2011) | 3 lines
Changed paths:
M /registry/trunk/public/webgl/sdk/tests/conformance/misc/object-deletion-behaviour.html


test that deleting a renderbuffer attached twice to the same framebuffer detaches it from the two attachment points.





On 30/11/11 06:50 PM, Kenneth Russell wrote:
On Wed, Nov 30, 2011 at 3:42 PM, Benoit Jacob<bjacob@mozilla.com> wrote:
On 30/11/11 06:21 PM, James Robinson wrote:



On Wed, Nov 30, 2011 at 10:38 AM, Kenneth Russell<kbr@google.com <mailto:kbr@google.com>> wrote:

    On Wed, Nov 30, 2011 at 8:52 AM, Benoit Jacob<bjacob@mozilla.com
    <mailto: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.


Sound like a good idea. May I add such a change while I'm at it? I don't see
right away any other functions in need for such a test, since other getters
returning objects explicitly return objects that have been explicitly
created (i.e. the spec already says that === should be true). I could be
missing something though.

Sounds fine to me. Let's take care of these corner case issues now rather than postponing them.

-Ken


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------