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

Wed Mar 13 21:51:18 PDT 2013

On Wed, Mar 13, 2013 at 9:49 PM, Gregg Tavares <gman at google.com> wrote:

>
>
>
> On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak <mjs at apple.com> 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 <vladimir at mozilla.com>
>> 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" <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
>>
>> _______________________________________________
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130313/788605af/attachment.html>