[Public WebGL] Why does the set of pname arguments for which the behavior of getShaderParameter is defined not match GL ES?

Boris Zbarsky [email protected]
Tue Apr 17 20:56:12 PDT 2012


On 4/17/12 11:04 PM, Glenn Maynard wrote:
> See sec 6.21; these functions aren't necessary with getShaderInfoLog and
> getShaderSoruce.  (That section doesn't actually specify anything, so it
> should probably be non-normative.)

Ah, I see.

>     At first glance, Gecko allows passing all 5 of the pname values
>     defined in GL ES.  Is the WebGL spec intending to disallow passing
>     INFO_LOG_LENGTH and SHADER_SOURCE_LENGTH?  If so, it might need to
>     explicitly say so somewhere....
>
> Those constants don't exist in the WebGL context.  Do you mean that
> Gecko passes these values along if you pass along the underlying
> constant (eg. usually 0x8B84 for GL_INFO_LOG_LENGTH)?

Yes, exactly.

> Do you think that needs to be specified explicitly?

Somewhere, yes.

> Constant values not mentioned in the spec should always be invalid

Saying that in a normative statement somewhere would cover this case, 
yes.  Makes for slightly confusing reading, of course, given the spec's 
"defer to ES" general structure: you have to know that you're supposed 
to defer to ES except in these various cases which are defined somewhere 
far far away from the definition of the actual method you're 
implementing....

 > I'm also not sure if ES actually defines the constant values for
 > named constants

Sorta.  Appendix E links to a place where you can get a header file that 
defines the various constants (with a "GL_" prefix).  I see nothing else 
in the spec defining them.

> It's probably worth having tests to make sure the typical underlying
> constants for those intentionally-unsupported enums are actually
> disallowed, at least.

Yes, like every normative requirement.

-Boris

-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------





More information about the public_webgl mailing list