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

Glenn Maynard [email protected]
Tue Apr 17 20:04:37 PDT 2012


On Tue, Apr 17, 2012 at 9:37 PM, Boris Zbarsky <[email protected]> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120417/05b65e67/attachment.html>


More information about the public_webgl mailing list