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

Vladimir Vukicevic vladimir at mozilla.com
Thu Mar 14 18:49:28 PDT 2013


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.

     - Vlad



More information about the webkit-dev mailing list