[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions
On Fri, Apr 23, 2010 at 09:33, Thatcher Ulrich <email@example.com>
I'm in favor of requiring the app to affirmatively do something in
Oh boy, I'm not a big fan of the implicit restore. (..)
order to restore a lost context.
As discussed before extensively, an implicit restoration model might have 'funny' visible consequences with apps not handling the event but loading resources _after_ initialization : newly loaded resources might be visible after implicit restoration but not older objects etc...
Ideally RestoredEvent (with no restore call) can be considered an explicit restoration model if the automatic restoration requires at least one event handler to be registered by the application (meaning the application has "done something") AND that the automatic restoration happens just before the event handler is executed. I think that's what Gregg was also implying in its latest message if I'm not mistaken.
In practice, I'm not sure it is simple to do with all DOM2 events implementations, so the Restorable+restore model probably is a simpler model in both implementation and documentation.
I support though that the restore() function should be member of the RestorableEvent interface, doing so makes clear that the method should only be called when the event has been dispatched, also it is more future-proof : if at some point we need/want RestoredEvent or a completely different context loss/restoration model (e.g callbacks interface based), we would have new events and/or new API but the restore() function would not pollute unnecessarily the WebGLContext API forever.