[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 17:29, Gregg Tavares <gman@google.com> wrote:
The problem as I see it is with ContextRestored,

Gregg, as discussed earlier we both agree that restoration with DOM events should follow an explicit restoration model (e.g RestorableEvent+restoreContext call), so let's forget about ContextRestored (implying implicit automatic restoration) for the sake of advancing the discussion.

my async functions all need to be tracked and dealt with since I have no control whether they complete on the restored context or the lost context.  That's what I meant by 3x-5x.

Here is the main misunderstanding between us imho, I believe you do not _need_ to track any of this, there is no benefit added complexity would bring over, for the simplest code, automatic failure in the callbacks (trying to load data into an invalidated WebGL object).
I've posted examples earlier demonstrating this.

With Reset, once I get to mainLoop I know all the async init functions have finished and every one of them was on the lost context so I know I can safely call reset and start them all over and they will all happen on the new restored context.

There is an assumption here that asynchronous resource loading only happens at initialization...
In reality async loading can happen at anytime during the lifecycle of an application (especially for networked/multi-user apps), you might need to load stuff after the mainloop has started and while it is running, hence the aforementioned issue is still valid and makes the potential advantage of isContextLost+reset moot : we cannot guarantee that completion of an asynchronous load will happen within the original context (which can be lost at any time).

Again my earlier async loading examples shows how to handle this with almost no added complexity (either fail and rely on the fact that a new async loading attempt will be initiated later anyways, either use a resource manager that creates a new WebGL object _at completion_ if the named resource has not been already loaded in current - possibly restored - context)


Here's the async version with reset
function mainLoop() {
  if (context.isContextLost()) {
    if (context.reset()) {

In your previous examples you are not using events at all, I have nothing against the use of reset() in general, otoh I'm concerned about not using events, replaced by polling (checking isContextLost() at every frame is what I mean by polling - this is less efficient and does not work with apps that do not refresh frames frequently).
If we do not have events at all, as implied by your recent examples, every app will have do to this kind of polling in one way or another - including apps that would otherwise 'wake up' infrequently (e.g at mouse click) in order not to show up a black canvas until next mouse click when a device resumes from standby.

If we have events, an abstraction working well in _javascript_ with any kind of WebGL app and which can be 'optimized' by WebGL implementations on mobile devices with asynchronous PM events, then I think it would be simpler to document and lead to more efficient WebGL apps in the wild if we make sure events are the only available mechanism. Having reset()/restore() as a member of the Resettable/Restorable event interface makes sure of that.