On Thu, Mar 14, 2013 at 7:45 PM, Dean Jackson <d...@apple.com> wrote:
> On 15/03/2013, at 12:49 PM, Vladimir Vukicevic <vladi...@mozilla.com> > wrote: > > 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. > > 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() ? - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev