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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions

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?

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