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

Re: [Public WebGL] webglcontextrestored, WEBKIT_lose_context

My nitpick is that I thought Glenn or Cedric pointed out early some far more standard spec language

For example in the video element spec. Every event that is sent async is listed in the form of

     when a lost context is detected queue-a-task to fire a simple event named webglcontextlost at the canvas element.

With each of those links live.

Similarly the exact algorithm is spelled out. 

It seems like that kind of wording should be used. In particular there needs to be a distinction between webglcontextcreationerror that it dispatched synchronously and the other events which are queued.

Also, it needs to be made clear (probably though a detailed algorithm) that regardless of whether or not the real OpenGL context is restored, from the point of view of WebGL and _javascript_ the new context must not be usable until webglcontextrestored is delivered.

Another words the algorithm is something like this

When a lost context is detected

1. the WebGLRendering context is marked as "lost". A WebGLRenderingContext marked as "lost" behaves as follows.
2. a queue-a-task to fire a simple event named webglcontextlost at the canvas element.

When the context has been restored

1. queue-a-task to fire a simple event named webglcontextrestored at the canvas element.

   Just before the event is dispatched, unmark the WebGLRenderingContext as "lost".

I'm sure that's clear as mud and that someone else can say this more clearly. What's important is that the WebGLRenderingContext stay marked lost until the event is dispatched, not when the context is restored. Otherwise the behavior is un

I also feel it's not clear from the spec that all the resources previously created must be invalid.