[Public WebGL] Null return values from create*

Kenneth Russell [email protected]
Fri Apr 13 18:30:40 PDT 2012

On Thu, Apr 12, 2012 at 3:38 AM, Tim Johansson <[email protected]> wrote:
> 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 set of functions where non-nullability could be enforced is only a
small percentage of the WebGL API. As Gregg pointed out, there are
very basic APIs like delete* and uniform* which have to accept null
WebGLObjects, and not even generate an error. Further, there were only
three functions -- bufferSubData, texImage2D and texSubImage2D --
where enforcing non-nullable "data" arguments was under consideration.
Therefore in my opinion it would be a bigger divergence from the rest
of the WebGL API if these functions didn't just generate an
INVALID_VALUE OpenGL error upon receiving null.

During development, a library like webgl-debug.js at
http://www.khronos.org/webgl/wiki/Debugging can turn all OpenGL errors
into exceptions for rapid debugging at the cost of performance.


> 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