A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

CanvasOpaque: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
Line 20: Line 20:
== Proposed Solutions ==
== 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.
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 ===
=== Suggested Solution ===

Revision as of 16:03, 17 April 2013

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

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

Non Goals

Proposed Solutions

One proposed solution was the opaque attribute on the canvas element. This was implemented by Mozilla and has been shipping in Firefox as the moz-opaque 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 getContext method, which specifies the context creation parameter object. The object contains the boolean alpha property:

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

Suggested IDL

interface Canvas2DContextAttributes {
    attribute boolean alpha;
};

interface Canvas2DRenderingContext {
    ...
    Canvas2DContextAttributes getContextAttributes();
}

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.