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

RE: [Public WebGL] appropriate context loss response

The appropriate response to context loss is documented in the WebGL spec, specifically section 5.15.2. (https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.15.2) The spec also has example code that illustrates how an application can handle context loss and restoration.  

I've pasted the important portions below:
	5.15.2 The Context Lost Event

	When the user agent detects that the drawing buffer associated with a WebGLRenderingContext context has been lost, it must run the following steps: 
	1. Let canvas be the context's canvas. 
	2. If context's webgl context lost flag is set, abort these steps. 
	3. Set context's webgl context lost flag. 
	4. Set the invalidated flag of each WebGLObject instance created by this context. 
	5. Disable all extensions except "WEBGL_lose_context". 
	6. Queue a task to perform the following steps: 0.0.1. Fire a WebGL context event named "webglcontextlost" at canvas, with its statusMessage attribute set to "". 
	6.1. If the event's canceled flag is not set, abort these steps. 
	6.2. Perform the following steps asynchronously. 
	6.3. Await a restorable drawing buffer. 
	6.6. Queue a task to restore the drawing buffer for context. 

	Example V The following code prevents the default behavior of the webglcontextlost event and enables the webglcontextrestored event to be delivered: 				canvas.addEventListener("webglcontextlost", function(e) { e.preventDefault(); }, false); 

	5.15.3 The Context Restored Event

	When the user agent is to restore the drawing buffer for a WebGLRenderingContext context, it must run the following steps: 
	1. Let canvas be the canvas object associated with context. 
	2. If context's webgl context lost flag is not set, abort these steps. 
	3. Create a drawing buffer using the settings specified in context's context creation parameters, and associate the drawing buffer with context, discarding any previous drawing buffer. 
	4. Clear context's webgl context lost flag. 
	5. Reset context's OpenGL error state. 
	6. Fire a WebGL context event named "webglcontextrestored" at canvas, with its statusMessage attribute set to "". 

	Non-normative: Once the context is restored, WebGL resources such as textures and buffers that were created before the context was lost are no longer valid. The application needs to reinitialize the context's state and recreate all such resources. 

Edge and IE detect D3D device removal and (barring any bugs) resets the D3D device such that the page can resume its business.  If the developer calls e.preventDefault, it can get back a new webgl context, as explained in the spec.  Since device removal can potentially destabilize other applications running on the system, Edge and IE reset into software mode to avoid repeated resets.  We do not reload the page.  

If you find bugs with IE and Edge's behavior, please let me know.


-----Original Message-----
From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Helmut Emmelmann
Sent: Wednesday, November 11, 2015 12:01 PM
To: Florian Bösch <pyalot@gmail.com>; Dean Jackson <dino@apple.com>
Cc: public webgl <public_webgl@khronos.org>
Subject: Re: [Public WebGL] appropriate context loss response

It would be very useful to somehow let the js code know that there is a problem, so that it can show alternate content e.g. simplified WebGL content or content not using WebGL at all. I am using WebGL in a way to improve the look of classical web pages and in this kind of application it is not a very big problem if the WebGL content does not show but its a big problem if it breaks the page completely.

Am 11/11/2015 um 7:01 PM schrieb Florian Bösch:
> As more JS/Canvas/WebGL is being embedded on third party pages around 
> the mobile web (because no flash), it becomes quite a bit of a problem 
> if iOS safari throws a hissing fit everytime an iFrame or WebGL 
> context on a page exceeds its (unknown and unknowable) resource limit 
> and therefore borks the whole page. But this is the WebGL 
> specification ML, we can't mandate that browsers behave nicely for 
> everything, we could mandate they don't throw hissing fits if WebGL is 
> being used in fashion that exceeds invisible resource limit border.
> On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson <dino@apple.com 
> <mailto:dino@apple.com>> wrote:
>>     On 11 Nov 2015, at 9:51 AM, Florian Bösch <pyalot@gmail.com
>>     <mailto:pyalot@gmail.com>> wrote:
>>     On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson <dino@apple.com
>>     <mailto:dino@apple.com>> wrote:
>>         I do think it should (must?) be "acceptable" to kill the
>>         process/page completely if necessary.
>>         Obviously detecting that the context is broken and firing a
>>         context lost event is the preferred option, but I don't think
>>         we can require all implementations to always recover gracefully.
>>     The issue is that if you kill the whole page, a reload will just
>>     kill it again in an endless loop (or however many auto-reloads iOS
>>     safari does by itself). It's night impossible to use iOS safari if
>>     it does that (closing the tab manually becomes quite challenging
>>     etc.). It also leaves the JS on the page with no clue that it did
>>     something bad (munch too much vram or whatever) and so no avenue
>>     to rectify/address the "bad" behavior. On the whole it's just
>>     really, really bad, is why I think it'd make a fairly good
>>     requirement for a specification.
>     Safari should only reload the page twice and then give up. It's
>     definitely a bug if it reloads constantly.
>     Dean
H.E.I. Informationssystems GmbH   |  Wimpfenerstraße 23 | 68259 Mannheim
Germany | Ph:+49 621-795141 | Fax: +49 621-7951 | emmel@taccgl.org
Geschäftsführer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091
             Handelsregister: HRB 7273 | Amtsgericht Mannheim
              http://www.taccgl.org   |   http://www.h-e-i.de

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with the following command in the body of your email:
unsubscribe public_webgl