On Thu, May 27, 2010 at 07:23, Kenneth Russell <email@example.com>
to implement these entry points but also support them for all of the
This assumption is incorrect. The core WebGL code will not only have
existing enums and values. See
note that all of the enums that can be passed to glTexParameter[if]
can also be passed to glTexParameter[if]v.
Right.ÂHowever this does not disprove the general idea that it requires only a minimal stub, passing control to the non-vectored version on the first element (ie. "gl.texParameteri(target, pname, param);" ) for the four valid enums.
Is this considered a significantly expensive stub to implement ?
What is the justification for adding these entry points? I am not
aware of any core OpenGL ES texture parameter, one specified by an
OpenGL ES extension, or any planned WebGL-specific texture parameter
that would require them.
Justification is being able to use them in _any_ extension, by your assumption that they are useless and always will be, ES would also have removed these signatures imho.
You're right that there is probably no ES extension requiring them currently, however this might happen during the lifetime of WebGL 1.0... and _there is_ non-ES extensions that requires them (e.g ARB_texture_swizzle is an obvious one, core now in 3.3+, but there is probably others), so WebGL bindings for desktop-specific extensions would need them.
Finally, do you imply every potential WebGL-specific extension should be been planned already ? ;-)ÂThe nice characteristic about an open extension system is that it can be used to experiment new ideas anytime, for instance a WebGL extension to support non-zero border (and associated TEXTURE_BORDER_COLOR parameter) on desktop could worthy to experiment [just an idea!].