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

Re: [Public WebGL] Return value for getAttachedShaders when a null program is passed in



On Sun, Apr 15, 2012 at 9:04 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
>
>
> ________________________________
>
> On Sun, Apr 15, 2012 at 10:16 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>
>> The spec doesn't seem to define what should happen when a null program is
>> passed to getAttachedShaders.  The OpenGL ES spec doesn't define behavior
>> here, since it uses an integer to identify the program, and that can't be
>> null.
>
>
> There's probably an ES spec bug there.
>
> In fact, the man page does say what should happen in this case:
> http://www.khronos.org/opengles/sdk/docs/man/xhtml/glAttachShader.xml
>
>   "GL_INVALID_VALUE is generated if either
>     program or shader
>     is not a value generated by OpenGL."
>
> But, I don't see where in the spec this is said. Section 2.10.3 in the
> OpenGL ES 2 spec doesn't seem to specify it, afaics.

For GetAttachedShaders and other queries, the beginning of Section
6.1.8 "Shader and Program Queries", page 129 of the ES 2.0.25 spec,
defines when INVALID_VALUE or INVALID_OPERATION errors are generated.

Similar text covering all of the mutators like AttachShader is at the
beginning of Section 2.10.1 "Loading and Compiling Shader Source".

In error conditions, a null return value is more consistent with the
other query methods. I've added clarifying text to getAttachedShaders,
getProgramParameter, getProgramInfoLog, getShaderParameter,
getShaderInfoLog, getShaderSource, getActiveAttrib, getActiveUniform,
getUniform, and getUniformLocation.

-Ken


> Benoit
>
>   However, the return value of functions that fail with an error isn't
> defined by OpenGL.  That's because it never (as far as I know) actually has
> return values, and always returns values into output parameters:
>
> void glGetAttachedShaders(uint program, sizei maxCount, sizei *count, uint
> *shaders);
>
> That sidesteps the question of what to return.  It simply doesn't modify the
> parameter, so the pattern in C becomes:
>
> int count = 0;
> int shaders[1024];
> glGetAttachedShaders(program, 1024, &count, shaders);
>
> In other words, the caller defines the return value, not OpenGL.  The result
> in WebGL is an ordinary return value, so the above no longer applies and
> WebGL does need to explicitly define the return value.
>
> This applies not only for null, but also if the program has been deleted, or
> if it's been invalidated due to a lost context.  (Currently, the lost
> context case is defined by 5.14 as returning null, but the null and deleted
> object cases aren't.)
>
>> Per current IDL, the return values that could possibly make sense are null
>> and empty array.  Gecko seems to return undefined or some such, based on
>> code inspection, which is clearly wrong, but I don't know which direction to
>> fix it in.
>
>
> I'd recommend returning an empty array, and generating INVALID_OPERATION.
> That way, this always works:
>
> var shaders = ctx.getAttachedShaders(program);
> for(var i = 0; i < shaders.length; ++i) ...
>
> rather than failing obscurely on context loss.  That would make the return
> value non-nullable, and add explicit context lost handling (so it can be
> applied to the context lost case too, as well as deleted and null objects).
>
> --
> Glenn Maynard
>
>

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