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

[Dean Jackson]

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.

Dean