[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="" would probably crash in gl
* 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

All the ones below here NEED to continue to allow NULL otherwise they will start throwing exceptions on context lost when all the createXXX functions start returning NULL.
* 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

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.


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