[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Florian Bösch [email protected]
Fri Feb 24 14:04:02 PST 2012


On Fri, Feb 24, 2012 at 10:31 PM, Ben Vanik <[email protected]> wrote:

> Playing with the EXT_texture_filter_anisotropic spec right now -- I think
> the constants should have the _EXT suffix. Looking at
> OES_texture_half_float and OES_standard_derivatives, the constants there
> have _OES. Since the original EXT_texture_filter_anisotropic constants have
> _EXT, they should probably match.

I disagree.

The EXT suffix on enumerants etc. serves the purpose to dissambiguate
extensions in the global namespace so that vendor specific extensions (NV,
ATI, SGI, etc.), non ratified but non vendor specific (EXT) fully ratified
extensions (ARB) and incorporated functionality (no suffix at all) do not
clash.

WebGL however uses a different mechanism to serve extensions. We serve
enumerants and symbols from the extension object, so no clashes with
incorporated functions or other extensions can occur.

A second motivation to append suffixes to enumerants and symbols is to make
people aware of the fact that they are using an extension. This again stems
from the fact that opengl et. al are one big global namespace. Again this
is not an issue for WebGL because in order to obtain the required symbols
specific to an extension, it is necessary to obtain the extension object,
such as the code below:

var extension = gl.getExtension('EXT_texture_filter_anisotropic')
extension.MAX_TEXTURE_ANISOTROPY_EXT

It is extremely unlikely that somebody would access the extension object
without being aware of accessing the extension object if there was no EXT
suffix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120224/3458dc2b/attachment.html>


More information about the public_webgl mailing list