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

[Rik Cabanier]

globalAlpha will still work but will always composite with an opaque
backdrop (which is black by default)


On Wed, Mar 13, 2013 at 3:25 PM, Elliott Sprehn <esprehn at chromium.org>wrote:

> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130313/c334311e/attachment.html>