On Wed, Mar 13, 2013 at 9:49 PM, Gregg Tavares <[email protected]> wrote:
> > > > On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak <[email protected]> wrote: > >> >> Two questions/comments: >> >> 1) What happens if I do: >> gl = canvas.getContext("experimental-webgl", { alpha: false }); >> and then later, in an unrelated piece of code I do the following on the >> same canvas: >> gl = canvas.getContext("experimental-webgl"); >> >> Will the canvas remain opaque? Will the buffer be wiped? Will it turn >> non-opaque without wiping the buffer? Based on my guesses of the answers to >> these questions, I feel like this approach is dangerous because you have to >> remember to pass the right parameters each time you retrieve the context. >> But really you should be able to set it once and then retrieve the context >> an arbitrary number of times without repeating yourself. >> > > > The parameters are ignored the second time. The spec already says you get > the same context that was create the first time you called getContext. > > > >> >> 2) I think alpha: false is a particularly bad name for the reasons >> Elliott stated - it sounds like it would disable all alpha compositing for >> all drawing operations done within the canvas, whereas what it actually >> does is force the composited results of canvas drawing to have alpha of >> 1.0. Is WebGL locked into the "alpha: false" syntax? >> > > "alpha: false" means there is no alpha channel, effectively making it 1.0. > You can't write to it. If you try to read it (readPixels, getImageData) all > the alpha data will be 255. It says nothing about compositing. But, the > fact that the UA knows this guarantees there is either no alpha or that > alpha is 1.0 through the entire surface means that UA and choose to render > without blending when appropriate. > s/and choose/can choose/ > > > > >> >> Regards, >> Maciej >> >> On Mar 13, 2013, at 7:57 PM, Vladimir Vukicevic <[email protected]> >> wrote: >> >> 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" <[email protected]> >> To: "Rik Cabanier" <[email protected]> >> Cc: "WebKit Development" <[email protected]> >> 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 < [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 >> >> _______________________________________________ >> 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
