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

Re: [Public WebGL] Null return values on context loss



On Tue, Nov 15, 2011 at 4:06 PM, Kenneth Russell <kbr@google.com> wrote:
Agreed -- the possibility of an exception at every entry point will
make it even more difficult to reason about the correctness of WebGL
programs.

Not all; some subset, whether it's "entry points with a non-null return value" or something even narrower. (Of course, there's inconsistency to that too--but all of these approaches have some kind of inconsistency to 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.

It's impossible to make everything just work, of course. But making 95% work, and reducing the "good practices" and special cases that people need to memorize to make sure their code falls in that 95%, is still a win.

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.

Specifying this generically could cover the majority of cases; for example, calls that would normally return Float32Array[2] would return {0,0}; boolean[4] would return {false, false, false, false}.

But I agree that it's not obvious whether this is the right way to go.

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.

I strongly disagree with the "you shouldn't be calling that anyway" line of reasoning. It's perfectly reasonable to call these functions, eg. during resource loads where causing a pipeline stall isn't a big deal. I've frequently called these sorts of functions (or rather, their OpenGL equivalents), to log all kinds of information to disk during loading. They only become a real problem once you hit your rendering loop, where pipelining becomes important.

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,

Demos aren't a good source of experience with API use in larger, production games and applications. Sample code actively tries to avoid the complexities of a real-world application. Real applications often have things like runtime diagnostics and similar more involved things that you don't see much in demos.

Out of curiosity, I look a quick look through webglsamples; in http://code.google.com/p/webglsamples/source/browse/tdl/programs.js#223:

>Â for (var ii = 0; ii < numAttribs; ++ii) {
>ÂÂÂ var info = gl.getActiveAttrib(program, ii);
>ÂÂÂ var name = info.name;

This will break if getActiveAttrib returns null. FWIW--not to pick on a random sample, but if Google-authored WebGL samples have trouble with this, it's going to be a problem in the wild.

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.

I'd expect this approach to lead to a lot of webapps with subtle context loss-related bugs.


Me:
> That was chosen arbitrarily; other examples are getContextAttributes, getSupportedExtensions, getAttribLocation, getProgramInfoLog, and so on.

(Scratch getAttribLocation.)

--
Glenn Maynard