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 <[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
