WHATWG Wiki - User contributions [en]

CanvasOpaque

2013-04-22T17:00:08Z

StephenWhite: /* Rationale: */

:''This proposal is to allow the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

When alpha is false, the per-pixel alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the attribute is not specified, the default value of "true" must be used instead.

When alpha is false, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). In addition, clearRect() clears to opaque black instead of transparent black.

The behaviour of putImageData() and putImageDataHD() is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store.

When a canvas has alpha: false, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the per-pixel alpha component is left unchanged at 1.0.

== Suggested IDL ==

<pre>
dictionary Canvas2DContextAttributes {
boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes? getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both canvas and WebGL.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. On subsequent calls to getContext(), the context attributes parameter is ignored.

== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-22T16:56:00Z

StephenWhite: /* Suggested IDL */

:''This proposal is to allow the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

When alpha is false, the per-pixel alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the attribute is not specified, the default value of "true" must be used instead.

When alpha is false, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). In addition, clearRect() clears to opaque black instead of transparent black.

The behaviour of putImageData() and putImageDataHD() is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store.

When a canvas has alpha: false, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the per-pixel alpha component is left unchanged at 1.0.

== Suggested IDL ==

<pre>
dictionary Canvas2DContextAttributes {
boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes? getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both canvas and WebGL.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.

== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-19T17:30:51Z

StephenWhite: /* Suggested IDL */

:''This proposal is to allow the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

When alpha is false, the per-pixel alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the attribute is not specified, the default value of "true" must be used instead.

When alpha is false, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). In addition, clearRect() clears to opaque black instead of transparent black.

The behaviour of putImageData() and putImageDataHD() is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store.

When a canvas has alpha: false, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the per-pixel alpha component is left unchanged at 1.0.

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes? getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both canvas and WebGL.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.

== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-19T14:43:38Z

StephenWhite: /* Suggested Solution */

:''This proposal is to allow the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

When alpha is false, the per-pixel alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the attribute is not specified, the default value of "true" must be used instead.

When alpha is false, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). In addition, clearRect() clears to opaque black instead of transparent black.

The behaviour of putImageData() and putImageDataHD() is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store.

When a canvas has alpha: false, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the per-pixel alpha component is left unchanged at 1.0.

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both canvas and WebGL.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.

== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T22:43:46Z

StephenWhite: /* Rationale: */

:''This proposal is to allow the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both canvas and WebGL.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.

== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T22:42:28Z

StephenWhite:

:''This proposal is to allow the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T19:48:04Z

StephenWhite: /* Goals */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (i.e., to leave all per-pixel alpha at 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T16:06:19Z

StephenWhite: /* Goals */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store for canvas.
# Modify all canvas operations to respect the opaque backing store (and leave it at alpha 1.0).
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T16:04:27Z

StephenWhite: /* Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T16:03:41Z

StephenWhite: /* Proposed Solutions */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque</code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

= Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs =

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T16:03:16Z

StephenWhite: /* Proposed Solutions */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was the <code>opaque>/code> attribute on the <code>canvas</code> element. This was implemented by Mozilla and has been shipping in Firefox as the <code>moz-opaque</code> attribute. Semantically, this is exactly what we want. However, it does not match WebGL syntax.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

= Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs =

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T16:01:39Z

StephenWhite: /* Proposed Solutions */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was implemented by Mozilla as the <code>mozOpaque</code> attribute on the <code>canvas</code> element. Semantically, this is exactly what we want. However, it does not match WebGL syntax, which already has such an API.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean <code>alpha</code> property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

= Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs =

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-17T15:51:22Z

StephenWhite: /* Suggested Solution */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was implemented by Mozilla as the <tt>mozOpaque> attribute on the <tt>canvas</tt> element. Semantically, this is exactly what we want. However, it does not match WebGL semantics, which already has such an API.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <code>getContext</code> method, which specifies the context creation parameter object. The object contains the boolean "alpha" property:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

= Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs =

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-16T22:08:44Z

StephenWhite: /* Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was implemented by Mozilla as the <tt>mozOpaque> attribute on the <tt>canvas</tt> element. Semantically, this is exactly what we want. However, it does not match WebGL semantics, which already has such an API.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <tt>getContext</tt> method, which can specify the "alpha" context creation parameter:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

= Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs =

The CoreGraphics API provides a mechanism to specify an opaque backing store, via kCGImageAlphaNoneSkipLast. However, it seems that IOSurfaces do not.

How the different APIs which do support such a mechanism behave with respect to different compositing modes is also TBD.

[[Category:Proposals]]

CanvasOpaque

2013-04-16T21:58:57Z

StephenWhite: /* Current Usage and Workarounds */

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. There is no known workaround for performance.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was implemented by Mozilla as the <tt>mozOpaque> attribute on the <tt>canvas</tt> element. Semantically, this is exactly what we want. However, it does not match WebGL semantics, which already has such an API.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <tt>getContext</tt> method, which can specify the "alpha" context creation parameter:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

[[Category:Proposals]]

CanvasOpaque

2013-04-16T21:58:18Z

StephenWhite:

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. Using WebGL might be a (rather heavy-handed) workaround in some cases, since WebGL already provides this API.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was implemented by Mozilla as the <tt>mozOpaque> attribute on the <tt>canvas</tt> element. Semantically, this is exactly what we want. However, it does not match WebGL semantics, which already has such an API.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <tt>getContext</tt> method, which can specify the "alpha" context creation parameter:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

[[Category:Proposals]]

CanvasOpaque

2013-04-16T21:57:46Z

StephenWhite: Created page with "Description: The "opaque" attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at al..."

Description:

The "opaque" attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the "opaque" attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead.

When a canvas has the opaque attribute, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). Setting, changing, removing or setting the attribute redundantly to its existing value causes the canvas to be cleared to the appropriate value.

When a canvas has the opaque attribute, clearRect() clears to opaque black instead of transparent black.

The behaviour of putImageData() and putImageDataHD() when a canvas has the opaque attribute is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store.

When a canvas has the opaque attribute, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the alpha component is left unchanged at 1.0.

:''This proposal is allowing the specification of an opaque backing store for 2D Canvas, to optimize blending and culling.''

== Use Case Description ==

Use case: A 2D UI is written using canvas which is attempting to achieve top performance. It clears its backing store to opaque, and only uses non-alpha-modifying canvas commands, but since the user agent cannot determine this empirically from an arbitrary set of canvas commands, it cannot optimize the blending and culling of obscured elements when compositing the canvas into the page.

=== Current Usage and Workarounds ===

Many sites already draw only opaque canvases, but have no way to convey this to the user agent. Using WebGL might be a (rather heavy-handed) workaround in some cases, since WebGL already provides this API.

Compositing a <canvas> element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas.

== Goals ==

# Allow the specification of an opaque backing store at getContext() time.
# Allow the user agent to easily optimize compositing and culling of the canvas.

== Non Goals ==

== Proposed Solutions ==

One proposed solution was implemented by Mozilla as the <tt>mozOpaque> attribute on the <tt>canvas</tt> element. Semantically, this is exactly what we want. However, it does not match WebGL semantics, which already has such an API.

=== Suggested Solution ===

Allow an optional parameter to the Canvas element's <tt>getContext</tt> method, which can specify the "alpha" context creation parameter:

<pre>
var ctx = canvas.getContext('2d', { alpha: false });
</pre>

== Suggested IDL ==

<pre>
interface Canvas2DContextAttributes {
attribute boolean alpha;
};

interface Canvas2DRenderingContext {
...
Canvas2DContextAttributes getContextAttributes();
}
</pre>

== Rationale: ==

'''Q:''' Why not add a new element attribute instead?

'''A:''' Implementing the same syntax as WebGL brings consistency to the web platform, obeys the principle of least surprise for developers. It also may allow more code sharing in JavaScript, since with duck typing, the same object can be used for both.
 

'''Q:''' Can you call getContext more than once on the same canvas, with different values for { alpha }?

'''A:''' No. Once it has been called once, the type of the backing store is set. Calling it again with a different argument raises an exception.
== Issues: ==

=== Implementing non-alpha-modifying compositing modes may be difficult in some 2D graphics APIs ===

[[Category:Proposals]]