[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 Tue, Apr 17, 2012 at 9:37 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
The spec defines the behavior of getShaderParameter for the following pnames: SHADER_TYPE, DELETE_STATUS, COMPILE_STATUS.

GL ES section 6.1.8 defines non-error-generating behavior of GetShaderiv for the following pnames: SHADER_TYPE, DELETE_STATUS, COMPILE_STATUS, INFO_LOG_LENGTH, SHADER_SOURCE_LENGTH.

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.)

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)?  Do you think that needs to be specified explicitly?  Constant values not mentioned in the spec should always be invalid, whether or not they happen to be defined by ES.  (I'm also not sure if ES actually defines the constant values for named constants, or if that's something implementations do without being required to; I suppose it must somewhere, since it'd be needed for ABI compatibility, but I can't find it...)

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

Glenn Maynard