[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Benoit Jacob [email protected]
Fri Feb 24 10:47:19 PST 2012


----- Original Message -----

> On Fri, Feb 24, 2012 at 12:43 PM, Benoit Jacob < [email protected] >
> wrote:

> > > > Would that mean that the getExtension calls adds a new property
> > > > to
> > > > the existing context object? That sounds a bit scary, and has
> > > > corner
> > > > cases that I'm not sure how to specify. What happens if the
> > > > user
> > > > has
> > > > already defined a UNSIGNED_INT property on it? Should it then
> > > > be
> > > > replaced? I'd rather keep it on the extension object.
> > > 
> > 
> 

> > > I was thinking that the context would already have the
> > > UNSIGNED_INT
> > > property, which would simply be rejected unless the extension was
> > > enabled. It doesn't seem like UNSIGNED_INT is really specific to
> > > that extension.
> > 
> 
> > OK, that's sensible, the only problem is that this requires a new
> > version of the WebGL spec, as opposed to just requiring an
> > extension. _If_ there is consensus that we want the index_uint
> > extension, then I'd be OK with your proposal for 1.0.2.
> 
> How does that require amending the spec? To write "UNSIGNED_INT" is
> allowed if this extension is enabled? Isn't that the purpose of the
> extension text? Anyways, if you specify "FLOAT", it is rejected; why
> would it require explicit language for negative cases?
See my reply to Ben Vanik --- I didn't realize that UNSIGNED_INT was already in the current spec. 

Benoit 

> > Benoit
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120224/8ef32ee5/attachment.html>


More information about the public_webgl mailing list