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

Re: [Public WebGL] Nullable changes in the spec



On Fri, Mar 16, 2012 at 8:17 AM, Tim Johansson <timj@opera.com> wrote:
>
> I have gone through the spec and marked the parameters and return values
> which must be nullable to pass the conformance test as nullable. Please
> verify the change in the spec.
>
> In many places making them nullable is clearly the right thing to do as the
> corresponding gl functions either needs a null value or silently ignores it.
> In other cases it is less clear because all null will do is raise a gl error
> and potentially result in an unexpected return value.
>
> The following cases currently accepts null and will only raise a gl error
> when passed null, I placed the most problematic or confusing ones first:
>
> * bufferSubData - Does not specify how it deals with data==null, would
> probably crash in gl

A null argument here is clearly meaningless to GL, so it doesn't seem
to me there is much value in synthesizing a GL error in response. I'd
support changing this to non-nullable, resulting in a TypeError if
null were passed. Other opinions?

> * readPixels - INVALID_VALUE on pixels==null, clearly stated in the spec.
> Would probably crash in gl. If texSubImage, bufferSubData, uniform*v and
> vertexAttrib*fv are not nullable I think this should match them for
> consistency

pixels==NULL is again meaningless to GL, so I'd support making this
argument non-nullable. Same for texSubImage. uniform*v and
vertexAttrib*fv are currently not nullable in the spec and I think
they should be left that way.

> * getAttachedShaders - INVALID_VALUE for program==null, returns null instead
> of empty list in this case, so it is highly likely to cause exceptions when
> using the returned object
> * getActiveAttrib - INVALID_VALUE for program==null, will return null
> instead of the expected WEBGLActiveInfo object (so does out of range index)
> * getActiveUniform - INVALID_VALUE for program==null, will return null
> instead of the expected WEBGLActiveInfo object (so does out of range index)
> * getAttribLocation - INVALID_VALUE for program==null, should probably
> return 0 on error according to the spec, we return -1 which IMO makes much
> more sense. If we want this nullable we should probably specify that return
> value (-1 is used for too long identifiers)
> * getUniform - INVALID_VALUE for program==null, INVALID_OPERATION if
> location==null. This will return null on error, so it will require extra
> checks regardless of if it is nullable or not
>
> * attachShader - INVALID_VALUE for program==null or shader==null
> * bindAttribLocation - INVALID_VALUE for program==null
> * compileShader - INVALID_VALUE for shader==null
> * detachShader - INVALID_VALUE for program==null or shader==null
> * getProgramParameter - INVALID_VALUE for program==null
> * getProgramInfoLog - INVALID_VALUE for program==null
> * getShaderParameter - INVALID_VALUE for shader==null
> * getShaderInfoLog - INVALID_VALUE for shader==null
> * getShaderSource - INVALID_VALUE for shader==null
> * getUniformLocation - INVALID_VALUE for program==null
> * linkProgram - INVALID_VALUE for program==null
> * shaderSource - INVALID_VALUE for shader==null
> * validateProgram - INVALID_VALUE for program==null

As Gregg points out, with the current context lost semantics, these
all have to support nullable arguments.

I'm increasingly in favor of changing the context lost behavior to
return invalidated objects from the create* methods, since it sounds
like that will unify a lot of behavior and allow a lot of error
handling spec text to be deleted. Will reply to the other thread Glenn
Maynard started.

> In addition to that the following are not very clear how to deal with:
> * isBuffer
> * isFramebuffer
> * isProgram
> * isRenderbuffer
> * isShader
> * isTexture
>
> They are very different from how they work in regular gl. In regular gl you
> pass in an integer and it will tell you if that name is a texture/buffer/...
> or not, it never generates an error. In WebGL you pass in an object of the
> correct type and the only thing it will tell you is essentially if the
> object has been explicitly deleted or not. In our implementation they are
> not nullable, so passing null will throw an exception. The conformance test
> does not require them to be nullable.

These also depend on the behavior of the create* functions when the
context is lost. Let's resolve that on the other thread. It seems that
it would be good to be able to keep their arguments non-nullable.

-Ken


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

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