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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>> > [email protected] >>>> > https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> > > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
