[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Kenneth Russell [email protected]
Fri Feb 24 10:21:00 PST 2012


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/

-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
-----------------------------------------------------------





More information about the public_webgl mailing list