[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Ben Vanik [email protected]
Fri Feb 24 14:19:55 PST 2012


Hmm I almost-half-agree, but disagree more ;)

1) I'm writing optimized code and am not using the values off of the
WebGLRenderingContext or the extensions, but instead defining my own
constants that are inlined by a compiler. Having the suffixes helps me keep
my constant namespace clean and *does* indicate that I am using an
extension. (see
http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/webgl/webgl.js
-
the Closure compiler can inline these, creating faster and smaller code)

Even if not doing something as complex as a compiler pre-pass/custom
constants/etc, in large code one would rarely be passing around a bunch of
extension objects. Instead, since the constants are fixed values, it's
easier to place them on a single object and pass that around, or keep them
globally defined somewhere.

2) WebGL has tried to keep the API and constants as similar to GL as
possible to aid in porting code/readability/discovery/etc. It of course is
not 100% the same, but one of the goals is to not break from GL where not
required. In this case, it's not required. Since the extension is EXT_....
and is designed to map to it, it follows that the constants and functions
inside of it should be 1:1. If not, it shouldn't be prefixed with EXT_ for
the same reasons.

3) The existing extensions are already following the pattern - as a bit of
a pedant, it pains me to see inconsistency forming in the WebGL specs so
early without good reason. Either we go back and change the existing specs,
or we keep the new ones consistent. Since we can't go back and change the
ratified specs without breaking code, I vote for keeping things the same.

On Fri, Feb 24, 2012 at 2:04 PM, Florian Bösch <[email protected]> wrote:

> 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/5cdb0b6d/attachment.html>


More information about the public_webgl mailing list