Canvas Context Loss and Restoration - Revision history

Junov at 21:31, 12 March 2014

2014-03-12T21:31:48Z

Junov: /* Processing Model */

2014-03-12T15:30:03Z

Processing Model

← Older revision		Revision as of 15:30, 12 March 2014
Line 65:		Line 65:

	:Opting-in to discardable backing stores.		:Opting-in to discardable backing stores.
	:* A new context creation parameter named 'storage' is to be added. Possible values are 'persistent' and 'discardable'.		:* A new context creation parameter named 'storage' is to be added. Possible values are 'persistent' and 'discardable'. Usage: canvas.getContext('2d', {storage: 'discardable'});
	:* In 'persistent' mode the UA may not elect to evict the canvas's backing store.		:* In 'persistent' mode the UA may not elect to evict the canvas's backing store.
	:* The default is 'persistent', which provides backwards compatible behavior for application that expect canvas backing store content to never be lost.		:* The default is 'persistent', which provides backwards compatible behavior for application that expect canvas backing store content to never be lost.
			:* Note: This parameter is a string rather than a boolean because it is anticipated that additional storage modes may be added in the future.

	==== Limitations ====		==== Limitations ====

Junov at 15:24, 12 March 2014

2014-03-12T15:24:17Z

← Older revision		Revision as of 15:24, 12 March 2014
Line 38:		Line 38:

	:Losing contexts (applies to 2d contexts, some aspects different for WebGL):		:Losing contexts (applies to 2d contexts, some aspects different for WebGL):
	:* ~~Intentional losses are~~ only allowed if ~~the contextRestored event is handled on the canvas element associated with~~ the context.		:* The UA is only allowed to lose contexts intentionally if the context was opted-in to have discarable storage (see below).
	:* The UA is free to use any set of rules to decide which contexts are dropped when and in what order.		:* The UA is free to use any set of rules to decide which contexts are dropped when and in what order.
	:* The return value of isContextLost() may transition from false to true before the contextLost event is dispatched (like webGL).		:* The return value of isContextLost() may transition from false to true before the contextLost event is dispatched (like webGL).
Line 63:		Line 63:
	:: a) If the canvas does not have an associated context, create an new unaccelerated context.		:: a) If the canvas does not have an associated context, create an new unaccelerated context.
	:: b) If the canvas already has an associate context, return the existing context even if it is in a lost state.		:: b) If the canvas already has an associate context, return the existing context even if it is in a lost state.

			:Opting-in to discardable backing stores.
			:* A new context creation parameter named 'storage' is to be added. Possible values are 'persistent' and 'discardable'.
			:* In 'persistent' mode the UA may not elect to evict the canvas's backing store.
			:* The default is 'persistent', which provides backwards compatible behavior for application that expect canvas backing store content to never be lost.


	==== Limitations ====		==== Limitations ====

Junov at 16:43, 28 January 2014

2014-01-28T16:43:19Z

← Older revision		Revision as of 16:43, 28 January 2014
Line 1:		Line 1:
	:2D Canvas Rendering contexts are currently required to have persistent backing stores. This proposal aims to relax that requirement by introducing an API to allows canvases to be discarded by the browser and re-drawn by the web application on demand.		:2D Canvas Rendering contexts are currently required to have persistent backing stores. This proposal aims to relax that requirement by introducing an API that allows canvases to be discarded by the browser and re-drawn by the web application on demand.

	== Use Case Description ==		== Use Case Description ==

Junov at 20:11, 4 December 2013

2013-12-04T20:11:25Z

← Older revision		Revision as of 20:11, 4 December 2013
Line 44:		Line 44:

	:Restoring contexts (applies to 2d contexts, some aspects different for WebGL):		:Restoring contexts (applies to 2d contexts, some aspects different for WebGL):
	:* Between the time a context is recovered and invoking the listener for the contextRestored event, no other user code can be executed.		:* Between the time a context is recovered and invoking the listener for the contextRestored event, no other user code can be executed. This is to prevent race conditions that could result from the rendering context validly executing draw commands before the contextRestored event is dispatched. To respect this constraint, a user agent that restores contexts asynchronously would have to behave as if the context was not yet restored between the time the context is restored internally and the time the contextRestored event listener is called.
	:* The app is responsible for re-creating the objects that were neutered when the context was lost.		:* The app is responsible for re-creating the objects that were neutered when the context was lost.
	:* There can only be one contextRestored event pending at a time. When there are multiple canvases to be restored, the next canvas to be restored can only be restored after any pending contextRestored events--from previously restored canvases--have been handled.		:* There can only be one contextRestored event pending at a time. When there are multiple canvases to be restored, the next canvas to be restored can only be restored after any pending contextRestored events--from previously restored canvases--have been handled.

Junov at 15:07, 22 October 2013

2013-10-22T15:07:52Z

← Older revision		Revision as of 15:07, 22 October 2013
Line 83:		Line 83:
	==== Open Issues ====		==== Open Issues ====
	:* Should there be a base CanvasRenderingContext interface that defines isContextLost and is inherited by both WebGLRenderingContext and CanvasRenderingContext2D?		:* Should there be a base CanvasRenderingContext interface that defines isContextLost and is inherited by both WebGLRenderingContext and CanvasRenderingContext2D?
	~~:* Should there be loseContext/restoreContext methods. Could be very useful for testing purposes, or for app-initiated resource management.~~


	[[Category:Proposals]]		[[Category:Proposals]]

Junov at 15:26, 21 October 2013

2013-10-21T15:26:49Z

← Older revision		Revision as of 15:26, 21 October 2013
Line 15:		Line 15:

	=== Benefits ===		=== Benefits ===

	:* Empower the browser to monitor resources to decide whether to drop canvas backing stores and in what order (LRU backgroung tabs?) in order to achieve better performance and stability. If web apps must handle resource eviction themselves, they may often free resources when not necessary, which may lead to unnecessary tab switching lag.		:* Empower the browser to monitor resources to decide whether to drop canvas backing stores and in what order (LRU backgroung tabs?) in order to achieve better performance and stability. If web apps must handle resource eviction themselves, they may often free resources when not necessary, which may lead to unnecessary tab switching lag.
	:* Make recovery from GPU context losses more robust.		:* Make recovery from GPU context losses more robust.
Line 21:		Line 20:

	=== Requests for this Feature ===		=== Requests for this Feature ===

	:* <cite>[https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/CQJXpXxO6dk E-mail thread on Chromium graphics-dev mailing list]</cite> <blockquote><p>"Is there any reason why we don't add a similar optional callback to the 2D context? (in reference to WebGL context loss API)" --Rik Cabanier, Adobe</p></blockquote>		:* <cite>[https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/CQJXpXxO6dk E-mail thread on Chromium graphics-dev mailing list]</cite> <blockquote><p>"Is there any reason why we don't add a similar optional callback to the 2D context? (in reference to WebGL context loss API)" --Rik Cabanier, Adobe</p></blockquote>

	== Proposed Solutions ==		== Proposed Solutions ==

	The following solutions were pondered in the discussion thread cited above:		The following solutions were pondered in the discussion thread cited above:
	:* Generalize the WebGL context lost / context recovered API, so that it applies to all types of canvases.		:* Generalize the WebGL context lost / context recovered API, so that it applies to all types of canvases.
Line 31:		Line 28:

	=== Retained Solution : Upstream the context lost/recovered API form the WebGL specification into the parent canvas specification. ===		=== Retained Solution : Upstream the context lost/recovered API form the WebGL specification into the parent canvas specification. ===

	:General Concept:		:General Concept:
	:* a renderingContextLost event is fired after the context is lost.		:* a renderingContextLost event is fired after the context is lost.
	:* a renderingContextRestored event is fired immediately after a previously lost canvas context is brought back to a usable state. The canvas context is returned to its initial state and the canvas's backing store is blank (transparent black) when restored.		:* a renderingContextRestored event is fired immediately after a previously lost canvas context is brought back to a usable state. The canvas context is returned to its initial state and the canvas's backing store is blank (transparent black) when restored.


	==== Processing Model ====		==== Processing Model ====
Line 81:		Line 76:
	:* Robustly recover from GPU failures.		:* Robustly recover from GPU failures.

	Top tier apps (particularly from developers that track usage metrics) would be expected to enthusiastically adopt this API.		:Top tier apps (particularly from developers that track usage metrics) would be expected to enthusiastically adopt this API.

	==== Specification ====		==== Specification ====
	: WebGL would continue to behave as currently specified (http://www.khronos.org/webgl/wiki/HandlingContextLost), but the wording of the WebGL specification could be modified to refer to the parent canvas specification and would only specify differences in behavior with respect to 2d canvas.		:WebGL would continue to behave as currently specified (http://www.khronos.org/webgl/wiki/HandlingContextLost), but the wording of the WebGL specification could be modified to refer to the parent canvas specification and would only specify differences in behavior with respect to 2d canvas.

	==== Open Issues ====		==== Open Issues ====

Junov at 15:23, 21 October 2013

2013-10-21T15:23:20Z

← Older revision		Revision as of 15:23, 21 October 2013
Line 16:		Line 16:
	=== Benefits ===		=== Benefits ===

	:* Empower the browser monitor resources to decide whether to drop canvas backing stores and in what order (LRU backgroung tabs?) in order to achieve better performance and stability. If web apps must handle resource eviction themselves, they may often free resources when not necessary, which may lead to unnecessary tab switching lag.		:* Empower the browser to monitor resources to decide whether to drop canvas backing stores and in what order (LRU backgroung tabs?) in order to achieve better performance and stability. If web apps must handle resource eviction themselves, they may often free resources when not necessary, which may lead to unnecessary tab switching lag.
	:* Make recovery from GPU context losses more robust.		:* Make recovery from GPU context losses more robust.
	:* Allow GPU-accelerated 2D canvases on platforms that are known to drop graphics contexts often or unpredictably.		:* Allow GPU-accelerated 2D canvases on platforms that are known to drop graphics contexts often or unpredictably.

Junov at 18:18, 18 October 2013

2013-10-18T18:18:39Z

← Older revision		Revision as of 18:18, 18 October 2013
Line 7:		Line 7:

	=== Current Limitations ===		=== Current Limitations ===
	:In theory, web apps do have the capability of discarding canvas backing stores (set canvas size to zero) and regenerating canvas ~~the~~ content. However, web apps are not and should not be expected to be responsible for resolving resource contention issues. The browser is responsible for monitoring resource usage and availability and is expected to take all necessary and reasonable measures to avoid crashes, hangs, and catastrophic performance degradations that may be caused by resource contention. Under the current specification, browsers have no options for evicting resources held by 2D canvases because there are no means of guaranteeing that the application will redraw the contents when needed.		:In theory, web apps do have the capability of discarding canvas backing stores (set canvas size to zero) and regenerating canvas content. However, web apps are not and should not be expected to be responsible for resolving resource contention issues. The browser is responsible for monitoring resource usage and availability and is expected to take all necessary and reasonable measures to avoid crashes, hangs, and catastrophic performance degradations that may be caused by resource contention. Under the current specification, browsers have no options for evicting resources held by 2D canvases because there are no means of guaranteeing that the application will redraw the contents when needed.

	=== Current Usage and Workarounds ===		=== Current Usage and Workarounds ===

Junov at 17:59, 18 October 2013

2013-10-18T17:59:51Z

← Older revision		Revision as of 17:59, 18 October 2013
Line 81:		Line 81:
	:* Robustly recover from GPU failures.		:* Robustly recover from GPU failures.

	Top tier apps from developers that track usage metrics would be expected to enthusiastically adopt this API.		Top tier apps (particularly from developers that track usage metrics) would be expected to enthusiastically adopt this API.

	==== Specification ====		==== Specification ====

← Older revision		Revision as of 21:31, 12 March 2014
Line 29:		Line 29:
	=== Retained Solution : Upstream the context lost/recovered API form the WebGL specification into the parent canvas specification. ===		=== Retained Solution : Upstream the context lost/recovered API form the WebGL specification into the parent canvas specification. ===
	:General Concept:		:General Concept:
	:* a ~~renderingContextLost~~ event is fired after the context is lost.		:* a contextlost event is fired after the context is lost.
	:* a ~~renderingContextRestored~~ event is fired immediately after a previously lost canvas context is brought back to a usable state. The canvas context is returned to its initial state and the canvas's backing store is blank (transparent black) when restored.		:* a contextrestored event is fired immediately after a previously lost canvas context is brought back to a usable state. The canvas context is returned to its initial state and the canvas's backing store is blank (transparent black) when restored.

	==== Processing Model ====		==== Processing Model ====
Line 40:		Line 40:
	:* The UA is only allowed to lose contexts intentionally if the context was opted-in to have discarable storage (see below).		:* The UA is only allowed to lose contexts intentionally if the context was opted-in to have discarable storage (see below).
	:* The UA is free to use any set of rules to decide which contexts are dropped when and in what order.		:* The UA is free to use any set of rules to decide which contexts are dropped when and in what order.
	:* The return value of isContextLost() may transition from false to true before the ~~contextLost~~ event is dispatched (like webGL).		:* The return value of isContextLost() may transition from false to true before the contextlost event is dispatched (like webGL).
	:* All objects that depend on the content of the canvas (e.g. patterns, imageBitmaps) are neutered when the context is lost. The neutering propagates through creation dependency chains, so a Pattern created from an ImageBitmap created from and ImageBitmap created from a canvas will be neutered if the canvas's context is lost. This rule makes it safe for implementations to optimize their memory consumption by sharing pixel buffers between objects when possible.		:* All objects that depend on the content of the canvas (e.g. patterns, imageBitmaps) are neutered when the context is lost. The neutering propagates through creation dependency chains, so a Pattern created from an ImageBitmap created from and ImageBitmap created from a canvas will be neutered if the canvas's context is lost. This rule makes it safe for implementations to optimize their memory consumption by sharing pixel buffers between objects when possible.
			:* The contextlost event does not bubble
			:* The contextlost event is cancellable. Cancelling the even has the effect of cancelling the future restoration of the context.

	:Restoring contexts (applies to 2d contexts, some aspects different for WebGL):		:Restoring contexts (applies to 2d contexts, some aspects different for WebGL):
	:* Between the time a context is recovered and invoking the listener for the ~~contextRestored~~ event, no other user code can be executed. This is to prevent race conditions that could result from the rendering context validly executing draw commands before the ~~contextRestored~~ event is dispatched. To respect this constraint, a user agent that restores contexts asynchronously would have to behave as if the context was not yet restored between the time the context is restored internally and the time the ~~contextRestored~~ event listener is called.		:* Between the time a context is recovered and invoking the listener for the contextrestored event, no other user code can be executed. This is to prevent race conditions that could result from the rendering context validly executing draw commands before the contextrestored event is dispatched. To respect this constraint, a user agent that restores contexts asynchronously would have to behave as if the context was not yet restored between the time the context is restored internally and the time the contextrestored event listener is called.
	:* The app is responsible for re-creating the objects that were neutered when the context was lost.		:* The app is responsible for re-creating the objects that were neutered when the context was lost.
	:* There can only be one ~~contextRestored~~ event pending at a time. When there are multiple canvases to be restored, the next canvas to be restored can only be restored after any pending ~~contextRestored~~ events--from previously restored canvases--have been handled.		:* There can only be one contextrestored event pending at a time. When there are multiple canvases to be restored, the next canvas to be restored can only be restored after any pending contextrestored events--from previously restored canvases--have been handled.
	:* Context restoration can only be initiated by the user agent (can not by triggered by a script action).		:* Context restoration can only be initiated by the user agent (can not by triggered by a script action).
	:* A lost context can only be restored after its context lost event has been dispatched. This avoids synchronization inconsistencies with isContextLost().		:* A lost context can only be restored after its context lost event has been dispatched. This avoids synchronization inconsistencies with isContextLost().
	:* The return value of isContextLost() transitions from true to false at the time that ~~contextRestored~~ event is dispatched (like webGL). So the ~~contextRestored~~ event listener is always the first task to be execute after the transition.		:* The return value of isContextLost() transitions from true to false at the time that contextrestored event is dispatched (like webGL). So the contextrestored event listener is always the first task to be execute after the transition.
			:* The contextrestored event does not bubble and is not cancellable.

	:Behavior when using a lost context (applies to 2d contexts, WebGL may behave differently):		:Behavior when using a lost context (applies to 2d contexts, WebGL may behave differently):