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

Re: [Public WebGL] Nullable changes in the spec



On Mon, Mar 19, 2012 at 5:44 AM, Tim Johansson <timj@opera.com> wrote:
> On 2012-03-16 18:58, Gregg Tavares (勤) wrote:
>
>
>
> 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
>> * 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.
>
>
> If the createXXX functions can return null they need to have their return
> type marked as nullable too. Are there any more functions I missed when
> adding nullable?

With the current assumptions, your current nullable changes look good.
Thanks for making them.

I'm increasingly in favor of the proposal to stop returning null from
createXXX when the context is lost, and will reply to the other thread
about that.

Will reply in more detail to your first email on this thread.

-Ken

> Also, even if the following functions allows nullable arguments we need to
> have a look at the values some of them return when they are passed null.
>
> //Tim
>
>
>> * 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.
>>
>> //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
-----------------------------------------------------------