On 3/14/2013 5:23 PM, Dean Jackson wrote:
On 15/03/2013, at 8:06 AM, Gregg Tavares <g...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
