[Public WebGL] Null return values from create*

Tim Johansson [email protected]
Thu Apr 12 03:38:25 PDT 2012


On 4/10/12 3:39 AM, Kenneth Russell wrote:

...

> Early in the development of the WebGL spec, every entry point raised
> DOMException, and exceptions were thrown for various error conditions
> that would be caught by the WebGL implementation, rather than the
> underlying OpenGL API. It was decided some time ago to unify the
> behavior to stop throwing exceptions and instead use OpenGL's error
> reporting mechanism -- synthesizing OpenGL errors where necessary. The
> reasons were that "real" errors in the application would necessarily
> be reported via OpenGL's getError() call; that debug wrappers could
> translate OpenGL errors into JavaScript exceptions anyway; and that
> applications should not need to use try/catch around every GL call in
> order to be robust.
>

We did agree to not throw exceptions for gl errors and invalid 
parameters, but we also agreed we would not try to avoid the exceptions 
thrown by WebIDL and make it a completely type-unsafe API.

We will throw exceptions if you pass in invalid types, and IMO null is 
an invalid type in many of these cases so to me it seems less consistent 
to accept null and raise gl errors when null is not valid. The only way 
to avoid that would be to change all functions to accept "any" which 
would be a big mistake IMO.

//Tim


> Gregg, given this history, I agree with you that it's a mistake to try
> to start throwing TypeError for a few methods on WebGLRenderingContext
> when they are passed null arguments. It would be asymmetric compared
> to the rest of the API.
>
> Given all of this, I've updated the editor's draft to reflect the
> current context loss specification:
>
>   - The various create() methods now return nullable types.
>   - The various is() queries accept nullable arguments.
>   - getSupportedExtensions(), getProgramInfoLog(), and similar queries
> now return nullable types.
>
> Missing text has been added to the spec for bufferSubData regarding
> the behavior when passed null. texImage2D and texSubImage2D now accept
> null for a couple more overloads, and generate an INVALID_VALUE error.
>
> webgl.idl has been rebuilt with these changes.
>
> Each of the edits was done separately so they can be examined
> independently; consult the Subversion history of
> specs/latest/index.html .
>
> http://www.khronos.org/bugzilla/show_bug.cgi?id=619 has been filed to
> track the needed conformance suite updates after all of the nullable
> changes in the spec.
>
> Please review these changes and send feedback to the list. Given the
> constraints, I think this is the best resolution, and hope that we can
> draw the nullable discussions to a close.
>
> -Ken
>
>
>> Note: getUniform like getParameter is also problematic.
>>
>>   var matrix = gl.getUniform(prg, modelViewMatrixLocation);
>>   var translation = matrix.slice(12, 3);  // crash
>>
>>> This would simplify the spec and
>>> implementations a fair amount -- it would no longer be necessary to
>>> explicitly generate an INVALID_VALUE OpenGL error for these entry
>>> points. It also unifies the behavior before and after context loss a
>>> fair amount.
>>>
>>> I don't know whether it's possible, or a good idea, to consider this
>>> proposal independently from other return values from getParameter,
>>> getActiveUniform, getUniformLocation, etc. It is probably impossible
>>> to guarantee that a WebGL implementation will return the same answers
>>> for calls like getActiveUniform before and after the context is lost,
>>> due to the asynchronous nature of context loss at the lowest level.
>>>
>>> There is definitely an argument that the current behavior is uniform.
>>> Every entry point, including the creation entry points, can start
>>> returning null essentially at any time. Also, if the behavior is
>>> changed, the 1.0.1 conformance suite will no longer run on future
>>> WebGL implementations, because it tests passing null for WebGLObjects
>>> and expects that no exceptions are thrown.
>>>
>>> What do you think? Is this worth pursuing?
>>>
>>> -Ken
>>>
>>>>>
>>>>>
>>>>>
>>>>>>> how about getParameter?
>>>>>>
>>>>>>
>>>>>> getParameter is hard, since there are a lot of possible arguments
>>>>>> with
>>>>>> varying reasonable "placeholder" results.  I'd defer this, too.
>>>>>>
>>>>>> While I'm thinking about it: does getParameter() define that values
>>>>>> like
>>>>>> MAX_VIEWPORT_DIMS and VIEWPORT always return a new object, as opposed
>>>>>> to
>>>>>> returning the same object each time?
>>>>>
>>>>> They should. I've clarified getParameter, getUniform and
>>>>> getVertexAttrib in this area.
>>>>>
>>>>> -Ken
>>>>
>>>>
>>
>>


-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------





More information about the public_webgl mailing list