[Public WebGL] oes-texture-float conformance

Glenn Maynard [email protected]
Tue May 10 10:52:02 PDT 2011


On Tue, May 10, 2011 at 8:52 AM, Benoit Jacob <[email protected]> wrote:

> Finally, I don't really see where in the spec these semantics are required.
> 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).
>

Wouldn't it be saner to do the exact opposite: require that getExtension
return a different object each time?  This is straightforward to test
without any GC complexities getting in the way.

This assumes that extension objects don't contain any state of their own;
that they only contain functions and constants and any related state is
stored in the WebGL context.  That seems to be how extensions are meant to
be implemented, so that seems reasonable; I don't know if there are any
reasonable cases where this might become an unwanted restriction.

> These semantics makes sense as an extension object should work no
> differently than other DOM JavaScript objects.

JavaScript objects don't all work this way.  Saving the first result and
returning it in the future is a getContext-specific thing; it doesn't
necessarily make sense to mimic it here, in a very different sort of API.

-- 
Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110510/ba79daeb/attachment.html>


More information about the public_webgl mailing list