[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Addition of texParameteriv and texParameterfv signatures



On Wed, May 26, 2010 at 6:47 PM, Cedric Vivier <cedricv@neonux.com> wrote:
> On Thu, May 27, 2010 at 07:23, Kenneth Russell <kbr@google.com> wrote:
>>
>> This assumption is incorrect. The core WebGL code will not only have
>> to implement these entry points but also support them for all of the
>> existing enums and values. See
>> http://www.khronos.org/opengles/sdk/docs/man/glTexParameter.xml and
>> 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[0]);" ) for the four
> valid enums.
> Is this considered a significantly expensive stub to implement ?

It requires handwritten code, and there is a recent push to eliminate
such handwritten code in the WebKit JavaScript bindings. Additionally,
balancing this against other needed work for WebGL 1.0, it would be
far down on my priority list.

>> 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!].

If an extension comes along which needs these entry points and they
aren't in WebGL 1.0 they can always be supplied on the extension
object itself.

Does anyone else on the WebGL working group have an opinion on this topic?

-Ken

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: