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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions

On Fri, Apr 16, 2010 at 12:11 AM, Chris Marrin <cmarrin@apple.com> wrote:

On Apr 15, 2010, at 1:44 AM, Gregg Tavares wrote:
...If it can be defined as described above, then the behavior would be equivalent to Resetable+reset().

No, it's not equivalent because in the Resetable+reset case the app gets to choose when the reset happens and therefore when WebGL functions will start working again.  In the Restored case the app doesn't get to choose. It always happens in his event handler or not at all, whether or not the app in a good state to deal with it.

Consider the following code.

function init() {
   var cube = GenerateVerticesForCube(ctx)
   var sphere  = GenerateVerticesFor100kPolySphereThatTakes10SecondsToComplete(ctx);

The 2 functions are synchronous. The functions follow the pattern...

function GenerateVertices___(ctx) {
   var verts = new WebGLFloatArray(numVerts);
   // compute vertices.
   var buf = ctx.createBuffer();
   ctx.glBindBuffer(ctx.ARRAY_BUFFER, buf);
   ctx.glBufferData(ctx.ARRAY_BUFFER, verts);
   return buf;

Because the code is synchronous, if the context is lost at 3 seconds and restored at 8 the code won't get the WebGLContextRestored event until after it's too late to do anything about it. 

But isn't this solve by my proposal that the context is not restored until the ContextRestored event is handled?

Okay, now I think we're getting confused.  The OpenGL context is restored as soon as it can be behind the scenes. The questions are when should that restored context be usable by WebGL and when should WebGL be told it's been restored..  You can't deliver a ContextRestored event if you haven't actually be able to restore the OpenGL context.

There are 3 versions of this so far

#1) The restored OpenGL context is available for use by the WebGL app the moment it's restored, separate from any events.

#2) The restored OpenGL context is not available for use by the WebGL app until the WebGLContextRestored event has been handled. If it's not handled the restored context is never usable by the WebGL app.

#3) The restored OpenGL context is not available for use by the WebGL app until it calls context.reset() where context.reset() has no effect until WebGLContextResetable is sent (handled or not)

#2 and #3 are 99% the same implementation. In both cases a flag has to be set inside WebGL that says "failAllCallsWithCONTEXT_LOST".  In #2 that flag gets cleared when WebGLContextRestored is handled. In #3 it gets cleared when context.reset() is called.

The difference IMO between #2 and #3 is #3 is has the advantage that the app gets to choose when that flag gets cleared, when WebGL will stop failing calls.  #2 the app does not get to choose. AFAIK there is no such thing as delaying handling an event. Your callback gets called outside of your control and when it returns the event is handled. (unless I don't understand what it means to *handle an event* in _javascript_)

The problem is that puts a lot of burden on the programmer to some how flag or stop any other asynchronous callback he has setup that started before the context was lost/restored among other things.

With the Reset/Resetable, the program is free to pretty much ignore the event system and just write this

var clearId;

function start() {
  clearId = setInterval(mainLoop, 10);

function mainLoop() {
  if (context.isContextLost()) {
    if (context.reset()) {

With Restored, it seems far more complicated.

I guess I don't see why Restored is better in this case since the developer loses control. If we are adding the requirement that the context is not actually usable until WebGLContextRestored is serviced then as the implementer you're already required to make the context fail all calls until it can deliver WebGLContextRestored *AND" WebGLContextRestored.  So, why is it better for that flag to automagically be set after that event handler returns vs making that flag settable by the user?

I'm fine with the Restorable+restore model if we have consensus. I just want to make the API as simple as possible