[Public WebGL] oes-texture-float conformance

Vladimir Vukicevic [email protected]
Tue May 10 11:32:47 PDT 2011



----- Original Message -----
> 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'.

In the Mozilla implementation, ext0 will always be == ext1, regardless of when you call getExtension.  The issue is really just whether additional properties that are defined on one object are visible on a later one, after the first one has gone out of JS scope (and been collected).

We have code that implements the same thing for some other dom objects, it's just a bit convoluted to add.  For most normal users, they can store whatever they want, e.g.:

 var ext = gl.getExtension('foo');
 ext.foo = 123;

as long as they hold on to ext somewhere.  The only place things break is if the user wants to store a property on the extension object, let all references to it go out of scope, and then get it again from gl.getExtension().  That seems like a really minor edge case, but I do agree that it's least surprising to have it actually work.  Even with the current Mozilla implementation, I don't think anyone will ever actually run into any problems, but the test does test a valid edge case.

    - Vlad

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