[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Benoit Jacob [email protected]
Fri Feb 24 10:44:02 PST 2012


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

> Wait, UNSIGNED_INT is already defined on WebGL context.
Dang! It is. That's what I didn't realize. Thanks! 

Benoit 

> I'd *strongly* prefer not to have it on the extension object.

> On Fri, Feb 24, 2012 at 10:38 AM, Benoit Jacob < [email protected] >
> wrote:

> > > On Fri, Feb 24, 2012 at 12:21 PM, Kenneth Russell <
> > > [email protected]
> > > >
> > > wrote:
> > 
> 

> > > > On Fri, Feb 24, 2012 at 2:01 AM, Florian Bösch <
> > > > [email protected]
> > > > >
> > > > wrote:
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell <
> > > > > [email protected]
> > > > > >
> > > > > 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 [email protected] .
> > > 
> > 
> 
> > > > To unsubscribe, send an email to [email protected] 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/6b4f9282/attachment.html>


More information about the public_webgl mailing list