[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Ben Vanik [email protected]
Fri Feb 24 10:42:16 PST 2012


Wait, UNSIGNED_INT is already defined on WebGL context. 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/8b853b87/attachment.html>


More information about the public_webgl mailing list