[Public WebGL] oes-texture-float conformance

Ben Vanik [email protected]
Tue May 10 11:12:23 PDT 2011


I've found the current behavior to be incredibly useful for a variety
of applications, as it makes the API feel more javascript-y - the
ability to modify objects however you want is one of the things that
makes the language so great.

I would not have been able to build debugging tools like WebGL
Inspector without the persistent objects, and I can imagine future
libraries that try to inter-operate requiring the behavior in order to
work well.

The DOM semantics Cedric mentions are things like getElementById
always returning the same object. 'get' is fairly explicit in letting
the caller know that it is getting an object - and the assumption
(from I'm assuming everyone who has ever coded) would be that a 'get'
would not return a new object each time - that would be
'createContext' or 'createExtension', which it is not. The fact that
it does the create under the covers on the first call is singleton
behavior, and hidden from the caller - for all they know every
possible context/extension type is created on startup. The only
weirdness here is that getExtension enables the extension on the first
call, but that is orthogonal to object persistence.

function renderFrame(gl) {
  var ext0 = gl.getExtension('foo');
  var ext1 = gl.getExtension('foo');
  assert(ext0 == ext1);
};
Having ext0 != ext1 would be odd. Again, 'get' means get, and no one
should have to know that 'getExtension' really means
'createExtension'.

On Tue, May 10, 2011 at 10:52 AM, Glenn Maynard <[email protected]> wrote:
> 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
>
>

-----------------------------------------------------------
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