[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Null return values from create*
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
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.
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
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.
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
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?
how about getParameter?
getParameter is hard, since there are a lot of possible arguments
varying reasonable "placeholder" results. I'd defer this, too.
While I'm thinking about it: does getParameter() define that values
MAX_VIEWPORT_DIMS and VIEWPORT always return a new object, as opposed
returning the same object each time?
They should. I've clarified getParameter, getUniform and
getVertexAttrib in this area.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: