[Public WebGL] oes-texture-float conformance

Kenneth Russell [email protected]
Tue May 10 09:52:22 PDT 2011

On Tue, May 10, 2011 at 6:46 AM, Cedric Vivier <[email protected]> wrote:
> On Tue, May 10, 2011 at 19:52, Benoit Jacob <[email protected]> wrote:
>> The other concern about this test is the GC part. What is window.GCController? Is that a WebKit-ism? Do we really want to have browser-specific code in conformance tests? Other browsers will use attemptToForceGC() which may or may not actually result in a GC run, giving non-deterministic results. In short, I question whether it's a good idea for a conformance test to rely on GC runs.
> I assume the intent is to test that the JavaScript object representing
> a WebGLExtension cannot ever be collected while the owner
> WebGLRenderingContext is alive, in order to provide singleton
> semantics within the context lifetime.

That's correct. This behavior matches the semantics of
Canvas.getContext(). See

For what it's worth, it wasn't completely trivial to make this work in
WebKit either, but since the spec was written in this way and since
Canvas.getContext() works similarly, we pushed to implement it.

The GCController is an interface available only in WebKit's automated
test harness. I agree it's not ideal to have browser-specific
constructs in the conformance suite, but using this interface makes
the test completely repeatable. Testing this behavior is important to
avoid regressions. If Firefox has a similar construct you should feel
free to add an arm to the test to use it. Also, if you have ideas for
how to make the attemptToForceGC function more deterministic, please
file bugs against the conformance suite.

> Technically this means an extension object instance must have a GC
> root to the WebGLRenderingContext object instance (ie.
> https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_AddRoot)
>> Section 5.13.14 says "Multiple calls to getExtension with the same extension string shall return the same object" but it's not entirely clear to me what that means in the case where the user modified that object in between, as we then have to choose between returning the modified object (behavior required by the test) or an object that is identical to the object that was returned the first time (which would be easy to implement).
> Afaik the intent of the spec is that former.
> These semantics makes sense as an extension object should work no
> differently than other DOM JavaScript objects.
> We should probably take the opportunity to clarify getExtension spec
> using imperative style (getContext-style) :
> [proposal]
> getExtensions(name) method of the WebGLRenderingContext, when invoked,
> must run the following steps:
> 1. Let name be the first argument to the method.
> 2. If extension name is not supported by this context, return null and
> abort these steps.
> 3. If the getExtension method has already been invoked on this context
> for the same extension name, return the same object as was returned
> that time, and abort these steps.
> 4. Return a new extension object.

This sounds good to me.


> Regards,
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list