[webkit-dev] New web-facing canvas feature: "opaque" attribute

Wed Mar 13 19:57:16 PDT 2013

WebGL chose alpha because it's a context creation attribute, to go along with other attributes like "depth" "stencil" etc.  It makes more sense for WebGL because there are a set of these.  For Canvas 2D, the only two that I think could apply are "alpha" and "preseveDrawingBuffer".  The canvas itself behaves normally.

moz-opaque was a hack when we saw that we could get a good speed win on mobile (since you can just blit instead of doing a blend); it came into being before the context creation attributes were added to the <canvas> spec.

I'd suggest adding context creation params to the canvas-2d context, to unify usage with WebGL and to make it easy to extend (e.g., preserveDrawingBuffer mentioned above).  Firefox may well even stop supporting moz-opaque; we never really publicized it anywhere and just used it internally in the Firefox UI.

    - Vlad

----- Original Message -----
> From: "Elliott Sprehn" <esprehn at chromium.org>
> To: "Rik Cabanier" <cabanier at gmail.com>
> Cc: "WebKit Development" <webkit-dev at lists.webkit.org>
> Sent: Wednesday, March 13, 2013 6:25:53 PM
> Subject: Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute
> 
> 
> 
> alpha:false is super confusing to me. It makes it sound as though all
> draw*() operations that use an alpha channel will fail... does
> globalAlpha still work?
> 
> 
> It's sad that WebGL picked such a generic name that isn't about all
> "alpha" related things.
> 
> 
> 
> On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier < cabanier at gmail.com >
> wrote:
> 
> 
> The main reason for this feature is to enhance performance of canvas
> operations.
> Are we certain that this will always be the case? For instance, is
> google going to make certain that the cairo and core graphics
> backends don't slow down?
> 
> 
> Rik
> 
> 
> 
> 
> On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones < bajones at google.com >
> wrote:
> 
> 
> 
> I think "opaque" vs. "alpha: false" is a matter of opinion. The
> functionality doesn't change, regardless of what you call it.
> 
> 
> I agree with Gregg that this really should be implemented to reflect
> the functionality that WebGL already has. Wether 2D or 3D, there's a
> lot of common ground between the various canvas contexts and it
> doesn't make much sense to reinvent the wheel when one context type
> has already implemented the functionality.
> 
> 
> --Brandon
> 
> 
> 
> 
> 
> On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak < mjs at apple.com >
> wrote:
> 
> 
> 
> 
> 
> An attribute on the canvas element would presumably be equally
> applicable to all contexts. Is there a reason that it's better to
> have opaqueness specified at context creation time instead of on the
> canvas? Also, I think "opaque" is easier to understand than "alpha:
> false".
> 
> 
> - Maciej
> 
> 
> 
> 
> 
> On Mar 13, 2013, at 9:57 AM, Gregg Tavares < gman at google.com > wrote:
> 
> 
> 
> 
> It would be nice if this was the same as WebGL instead of different.
> Especially because 2d canvas and WebGL need to inter-operate in the
> near future.
> 
> 
> In WebGL to create a canvas with no alpha (an opaque canvas) you do
> this
> 
> 
> gl = canvas.getContext("experimental-webgl", { alpha: false });
> 
> 
> Why can't 2D canvas be this
> 
> 
> ctx = canvas.getContext("2d", {alpha: false});
> 
> 
> As for why this is important to be the same see the proposal for
> Canvas in Workers here ( http://wiki.whatwg.org/wiki/CanvasInWorkers
> )
> 
> 
> In that proposal the "backingstore" of a canvas can be moved to/from
> a worker. That solution may or many not be the final solution but it
> points out that whatever solution is chosen we need the solution to
> work for both canvas 2d and WebGL and as such needs a common way to
> create backing stores with no alpha.
> 
> 
> 
> 
> 
> On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze < dschulze at adobe.com >
> wrote:
> 
> 
> This is a very long thread and I did not see any conclusions or
> agreement on this thread. Can you summarize the topic and the status
> on the acceptance level please?
> 
> Greetings,
> Dirk
> 
> 
> 
> On Mar 13, 2013, at 9:15 AM, Stephen White < senorblanco at chromium.org
> > wrote:
> 
> > Hi WebKittens,
> > 
> > I'm planning to implement the canvas "opaque" attribute, as
> > proposed here:
> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html
> > .
> > 
> > This is an attribute that causes the allocation of an opaque
> > backing store for <canvas>, allowing optimizations at the time the
> > canvas is composited into the page, such as disabling blending and
> > culling obscured content. It is based on the moz-opaque attribute
> > currently shipping in Firefox.
> > 
> > I'll be placing the feature behind the build-time flag
> > ENABLE(OPAQUE_CANVAS).
> > 
> > Let me know if you have any comments or concerns.
> > 
> > Stephen
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 