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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions





On Mon, Apr 12, 2010 at 11:08 AM, Cedric Vivier <cedricv@neonux.com> wrote:
On Mon, Apr 12, 2010 at 10:03, Gregg Tavares <gman@google.com> wrote:
These are great examples. I don't follow your conclusion though.  In the first example getting GL_INVALID_OPERATION in no way informs you that you happened to have lost the context for a moment during initialization.

True, I'm not sure it is necessary but I agree the more specific the errors the better usually so we can just define that attempt to bind/use an invalidated WebGL object generates a GL_INVALID_NAME error instead right?

If we make up GL_INVALID_NAME is it only for names from lost contexts or is it also for names from other contexts? That seems like a confusing enum. If we go this route it should be GL_INVALID_OBJECT_FROM_LOST_CONTEXT


 
Where is with the Resetable/Reset method you'd get GL_CONTEXT_LOST on all those operations and any other operations until you choose to reset.

Yes, exactly as it would be the case with Restored as far as I can see in the explored scenario of completion of asynchronous resource loading after original context has been lost AND subsequently restored, assuming a Resetable event handler like this 

function onResetableEvent() {
    ctx.resetContext();
    reloadAssets();
}

With the first example it would still fail since object has been invalidated, with the second example it would load the resource in GL possibly loading same texture twice in VRAM if there is no additional checks.



I think we all agree that Restored is not such a good idea if it cannot be defined/implemented with context restoration only just before the event is handled by user code.
If an app does not handle any context loss event the app should just stop working, automatic restoration whether or not the app actually even try to handle it would be confusing for both developers and users.

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. 

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?