[webkit-dev] New web-facing canvas feature: "opaque" attribute
Maciej Stachowiak
mjs at apple.com
Wed Mar 13 21:20:53 PDT 2013
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.
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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130313/1a458c47/attachment-0001.html>
More information about the webkit-dev
mailing list