[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

[Benoit Jacob]

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

> On Fri, Feb 24, 2012 at 12:21 PM, Kenneth Russell < kbr...@ >
> wrote:

> > On Fri, Feb 24, 2012 at 2:01 AM, Florian Bösch < pya...@ >
> > wrote:
> 
> > >
> 
> > >
> 
> > > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell < kbr...@
> > > >
> > > wrote:
> 
> > >>
> 
> > >> Are there any objections to moving this WebGL extension into
> > >> draft
> 
> > >> state? I don't suspect there would be...
> 
> > >
> 
> > > No objection.
> 
> > >
> 
> > >>
> 
> > >> No objections to incorporating a conformance test for it as long
> > >> as it
> 
> > >> passes without the extension being available
> 
> > >
> 
> > > This behavior is implemented by the conformance test. For
> > > cross-vendor
> 
> > > support the queried extension would have to be either of
> 
> > > MOZ_EXT_texture_filter_anisotropic,
> > > WEBKIT_EXT_texture_filter_anisotropic or
> 
> > > EXT_texture_filter_anisotropic, do you want me to provide a patch
> > > to the
> 
> > > conformance test for that?
> 
> > >
> 
> > >>
> 
> > >> and is prefixed with a
> 
> > >> minimum version of 1.0.2.
> 
> > >
> 
> > > How do I prefix the test?
> 
> > >
> 
> > >> All that's needed to change the state
> 
> > >> is change one keyword in the extension.xml, move it out of the
> 
> > >> "proposals" folder and re-run make.
> 
> > >
> 
> > > Should I provide the patch to the specification?
> 
> > >
> 
> > >
> 
> > > As to the life/implementation of specifications, I'm not entirely
> > > clear on
> 
> > > how that works. So I propose the following (arguable)
> > > formalization:
> 
> > >
> 
> > > Lifecycle of an extension: proposal -> draft -> ratified
> 
> > > Lifecycle of implementations:
> 
> > > - proposal: may implement but with vendor prefix, implementation
> > > is
> > > subject
> 
> > > to removal again if failing to move on to draft.
> 
> > > - draft: may implement without vendor prefix, implementation is
> > > subject to
> 
> > > removal again if failing to move on to ratified.
> 
> > > - ratified: should implement without vendor prefix,
> > > implementation
> > > may not
> 
> > > be removed again, web-developers can now trust this being
> > > supported
> > > by
> 
> > > vendors.
> 
> > >
> 
> > > Please help me get this formalized to everybodies satisfaction,
> > > so
> > > we can
> 
> > > create an extension guide from it.
> 

> > Agree that we should formalize the process. I believe the
> 
> > implementation lifetime should be as follows:
> 

> > - Proposal: for discussion on the public mailing list only, in
> > order
> 
> > to move to draft status. Must not be implemented by any vendor in
> > this
> 
> > form.
> 
> > - Draft: may be implemented with vendor prefix. For experimentation
> 
> > purposes, to gain experience with the extension before finalizing.
> 
> > - Ratified: should be implemented without vendor prefix. Should not
> 
> > be removed except if there is a security issue or similar.
> 

> > Thoughts?
> 

> > Also, I'd like to propose we move OES_element_index_uint and
> 
> > WEBGL_depth_texture from proposal state to draft state; these seem
> 
> > non-controversial. Objections or support?
> 

> > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/
> 
> > http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/
> 
> > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/
> 

> I know it seems consistent to do OES_element_index_uint.UNSIGNED_INT,
> but will this token be duplicated later? Isn't it sufficient to
> simply allow UNSIGNED_INT where the extension allows it?
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. 

Benoit 

> > -Ken
> 

> > -----------------------------------------------------------
> 
> > You are currently subscribed to pub...@ .
> 
> > To unsubscribe, send an email to maj...@ with
> 
> > the following command in the body of your email:
> 
> > unsubscribe public_webgl
> 
> > -----------------------------------------------------------
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120224/8ed54096/attachment.html>