[Public WebGL] proposal draft for EXT_texture_filter_anisotropic
Mon Feb 27 18:22:24 PST 2012
----- Original Message -----
> On Fri, Feb 24, 2012 at 10:36 AM, Benoit Jacob <[email protected]>
> >> 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?
> > OK to formalize the notion that proposals should be made drafts
> > before implementation starts (will do next time).
> > Could we also formalize that once an extension is ratified, not
> > only it should be implemented without vendor prefix, but any
> > browser that already has an implementation with prefix should
> > remove support for the prefixed extension string as soon as
> > possible, even if this breaks content?
> Does the text just added to
> http://www.khronos.org/registry/webgl/extensions/ address your
> concern? If not, let's make it more explicit.
What I'm trying to avoid, is the problem where prefixed features stay around long after they have been standardized and available without prefix. This leads to a situation where some Web content keeps using the prefixed feature, and thus, keeps working only with the browser engine that they initially targeted.
To prevent that, I think that we should mandate that as soon as a feature becomes available without prefix, support for the prefix should be dropped. The downside is of course that this breaks content, but it could hopefully be made clear enough that prefixes can go away at any time, and content that cares about future compatibility could simply start checking for the non-prefixed name as a fallback, before the prefix gets dropped.
Does that make sense? I'm happy to edit the document to that effect, if you agree.
> >> 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?
> > About OES_element_index_uint, is there a use case where this is a
> > significant performance win, or is this is just a convenience
> > extension? Is it worth the portability issues it introduces?
> The main portability issue with OES_element_index_uint has been
> addressed with support for the extension in iOS 5. See
> > I support depth textures.
> Great. I'll still start up a separate thread about moving these out
> proposals in case anyone missed this discussion here.
> > Benoit
> >> 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/
> >> -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:
More information about the public_webgl