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

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

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.


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:
unsubscribe public_webgl