[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Ben Vanik [email protected]
Fri Feb 24 15:33:17 PST 2012

It has a bearing when one of your reasons for dropping the suffix is that
the namespace collisions are no longer a problem - I'm telling you they
still are ;)

Excellent. I've got a patch in the works for WebKit/Chrome for

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

> On Fri, Feb 24, 2012 at 11:19 PM, Ben Vanik <[email protected]> wrote:
> How you structure your application and what you prefer doing with your
> namespaces has no bearing on the discussion.
>> 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.
> I do concede the point, it is inconsistent to other extensions thus far.
> Interestingly I did not notice that (and neither did anybody else except
> you), which kind of illustrates an intuitive point about it. On any
> account, I can provide patches to the specification and implementations if
> required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120224/1c794f65/attachment.html>

More information about the public_webgl mailing list