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

[Gregg Tavares]

On Thu, Mar 14, 2013 at 7:47 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Thu, Mar 14, 2013 at 7:45 PM, Dean Jackson <dino at apple.com> wrote:
>
>> On 15/03/2013, at 12:49 PM, Vladimir Vukicevic <vladimir at mozilla.com>
>> wrote:
>> > On 3/14/2013 5:23 PM, Dean Jackson wrote:
>> >> On 15/03/2013, at 8:06 AM, Gregg Tavares <gman at google.com> wrote:
>> >>> Because it's not the same as fillRect(0, 0, width, height) on an
>> empty canvas. The canvas itself has alpha (unless we add the option to not
>> have it as has been proposed). The contents of the canvas has to stay as
>> the user created it. If I draw with rgba(255,255,0, 0.5) I expect if I read
>> data out of the canvas or draw that canvas into another canvas I'll get
>> that color, not the color blended with the css background.
>> >> Yes, this is what I said in another email. Maybe I'm misunderstanding
>> this, but if the main concern is to guarantee nice subpixel-antialiased
>> text in canvas (but not anywhere else, such as the 99.99% of places where
>> people draw text) then.... well, I'm still not convinced opaque is a great
>> idea :) Especially not as an HTML attribute.
>> >
>> > The main concern for us was performance -- if you have a large canvas,
>> whether on mobile or on desktop, it is beneficial to tell the browser that
>> it is guaranteed opaque, and it can allocate backing store and draw it as
>> such.  There's no way to infer that... checking the CSS background doesn't
>> work for the reasons Gregg outlined.  Basing it on a fillRect() of the
>> entire canvas with a non-opaque color doesn't work, because there are blend
>> modes that will punch holes in alpha.  So you can have a really complicated
>> heuristic to try to get it right and miss in a bunch of cases, or you can
>> just "make it work" in the general case (have alpha), and let developers
>> who are trying to squeeze the last bit of performance out of the platform
>> give you the hints you need.  We opted for the latter approach.
>>
>> Fair enough. I'm not arguing against the benefits - as I said, we get the
>> request all the time. I'm just hoping there is a way we can do this for
>> more elements than just canvas.
>>
>> If we do decide this is canvas only, I don't like an attribute on the
>> element. That seems too presentational. It's the script that decides what
>> is drawn into canvas, so the script should probably decide whether or not
>> to tell the implementation it might be able to optimise by not allocating
>> an alpha channel. So count me in the camp that agrees with context
>> attributes.
>>
>> Just calling it "alpha" is also a bit confusing, because alpha will still
>> work within the canvas itself.
>>
>
> How about canvas.makeOpaque() ?
>

I don't understand the opposition to "alpha"

You set colors in Canvas2d with rgb or rgba. That 'a' in rgba stands for
alpha.
You can set a global alpha for drawing with context.globalAlpha
You read data from getImageData that returns red, green, blue, alpha
You write data to putImageData wit red, green, blue, alpha

So why name an option that effectively removes the alpha something not
called "alpha"?  I have no better idea what "opaque" means. As far as I
know it just means blending won't happen during compositing but alpha still
exists when I draw and when I read from the canvas. That seems more
confusing to me.

I also don't understand why if getContext("webgl", { alpha: false }) has
been shipping for 3 years there's a need to make it different on canvas 2d?
Picking a different name or picking a different method (a function, an
attribute on canvas or context) seems like bikeshedding rather than some
functional objection. There's a solution, it has existed and been shipping
in WebKit for 3 years. Can't we just go with that? Developers will be no
more confused by this than whether drawImage is drawImage(img, x, y) or
drawImage(x, y, img). You look up once in a while.

As far as the spec goes, the effect of setting alpha:false is as if every
draw operation ended with

   dest = RGBA | 0x000000FF

That means everything works as speced. getImageData will pull out RGBA but
A will always be 255. Every draw call including putImageData follows the
rule above.  How that effects compositing is not a normative part of the
spec. It's just something UAs happen to know they can do.




>
> - R. Niwa
>
>
> _______________________________________________
> 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/20130315/d780fcf6/attachment.html>