[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Patrick Baggett [email protected]
Fri Feb 24 10:35:31 PST 2012


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?


> -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/97d991f2/attachment.html>


More information about the public_webgl mailing list