[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Ben Vanik [email protected]
Fri Feb 24 10:52:22 PST 2012


Indeed.
Benoit - these constants are already defined on WebGLRenderingContext, and
with the same constant values. No need to bump the spec. Hooray less work!

On Fri, Feb 24, 2012 at 10:45 AM, Patrick Baggett <[email protected]
> wrote:

>
>
> On Fri, Feb 24, 2012 at 12:43 PM, Benoit Jacob <[email protected]> wrote:
>
>>
>>
>> ------------------------------
>>
>>
>>> 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.
>>>
>>>
>> I was thinking that the context would already have the UNSIGNED_INT
>> property, which would simply be rejected unless the extension was enabled.
>> It doesn't seem like UNSIGNED_INT is really specific to that extension.
>>
>> OK, that's sensible, the only problem is that this requires a new version
>> of the WebGL spec, as opposed to just requiring an extension. _If_ there is
>> consensus that we want the index_uint extension, then I'd be OK with your
>> proposal for 1.0.2.
>>
>
> How does that require amending the spec? To write "UNSIGNED_INT" is
> allowed if this extension is enabled? Isn't that the purpose of the
> extension text? Anyways, if you specify "FLOAT", it is rejected; why would
> it require explicit language for negative cases?
>
>
>>
>>
>> Benoit
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120224/7329b2ef/attachment.html>


More information about the public_webgl mailing list