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

[Ryosuke Niwa]

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

That sounds horribly confusing. Can we please change this API?

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

I agree with others that this is a very misleading name. I get the
sentiment of it but it's a bad name nonetheless.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130313/6cf68153/attachment.html>