[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 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?

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() {

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().