[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
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.
- The context's
isContextLost
method returns true
.
- All methods returning
void
return immediately.
-
All methods returning nullable values or
any
return null
.
-
checkFramebufferStatus
returns FRAMEBUFFER_UNSUPPORTED
.
-
getAttribLocation
returns -1
.
getError
returns CONTEXT_LOST_WEBGL
the first time it is called while the context is lost. Afterward it will return NO_ERROR
until the context has been restored.
getVertexAttribOffset
returns 0
.
- All
is
queries return false
.
When the context has been restored
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.