[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Null return values on context loss
On Sun, Nov 13, 2011 at 12:25 PM, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:
> On Sat, Nov 12, 2011 at 11:22 PM, Glenn Maynard <email@example.com> wrote:
>> When the context is lost, "methods returning nullable values or any return
>> null". This seems very hard to deal with correctly, since you have to deal
>> with a very rare return value. For example,
>> return ctx.getVertexAttrib(idx, ctx.CURRENT_VERTEX_ATTRIB);
>> will fail if the context is lost, since attr will be null. This requires
>> C-style per-call error handling, which makes it hard (and tedious) to write
>> correct code.
> Correct. Yet except for debugging apps there is generally no reason to call
> ctx.getVertexAttrib. Of course that doesn't mean we shouldn't fix this
>> It seems like the expectation was that null returns would work implicitly,
>> without the caller needing to check for null. That mostly works for things
>> like WebGLTexture, which has no methods and is only passed to functions
>> which accept null. However, it doesn't seem like this holds consistently
>> throughout all affected API calls.
> It works for WebGLTexture unless you do this
> tex = gl.createTexture();
> tex.url = urlOfImageImPuttingInTexture
> I had to fix code that did that when I made the code handle lost context.
>> I'm not sure what the right thing to do would be, though. Throwing an
>> exception would be an improvement, at least.
> No that would be just as a bad if not worse.
Agreed -- the possibility of an exception at every entry point will
make it even more difficult to reason about the correctness of WebGL
programs. Early versions of the WebGL spec did have the possibility of
throwing DOMException from every method because some errors were
reported as OpenGL errors and some (WebGL-specific) were raised as
exceptions. This was changed in May 2010 after a working group
face-to-face where it was settled that synthetic OpenGL errors would
be used to report the latter. (See the revision history for
specs/latest/index.html in the WebGL repo.)
>> Also, the above says "nullable values". I assume that "nullable types"
>> was intended, eg. http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type,
>> but as far as I can find, there are no nullable types (eg. "DOMString?") in
>> WebGL's IDL. Based on what's actually happening here (most functions can't
>> return anything meaningful when the context is lost), I'm guessing it was
>> intended that *all* (or almost all) non-null return values in WebGL be
Yes, this was the intent. Perhaps this fix should be done now to at
least make it self-consistent while we figure out whether to change
the spec further.
> Ideally, each function would return something that is unlikely to break
> We can either change the spec or add some examples (or a link to
> examples) showing the correct usages. Something like this
> with more examples added for getVertexAttrib etc.
Even if the spec is changed to return non-null values from various
entry points, it's unavoidable that some change in behavior will be
seen by applications calling them.
Consider getActiveUniform for example. If the context has been lost,
it's unlikely that a WebGL implementation will be able to synthesize a
WebGLActiveInfo that contains fully correct information. Perhaps the
"DOMString name" will be empty; this change might cause an application
to break. getParameter returns a lot of other OpenGL state which it
might not be feasible to mirror in order to produce the exact same
results as before the context was lost.
Changing the spec to return non-null objects from the various get and
create methods will require each query's behavior under lost context
to be individually specified. This is a *lot* of text to add to the
spec. The benefit needs to be carefully weighed. Applications should
not be calling the problematic get methods at all at runtime for
performance reasons, and it should be straightforward to check the
return values from the create methods.
Gregg probably has more experience with handling lost context than any
other WebGL developer at this point so I defer to his judgment. It
seems that it was feasible to update the webglsamples and Khronos
WebGL demos with the current context lost semantics, so any changes to
the spec in this area should be strongly motivated with example
applications. Instead I'd rather expand his context lost wiki page
above with more examples and encourage developers to stress test their
applications using webgl-debug.js' synthetic context loss.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: