On Thu, Mar 14, 2013 at 5:23 PM, Dean Jackson <d...@apple.com> 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. > > There are obviously ways to get around the problems you mentioned above > (e.g. two buffers + two draws, or keeping a display list until someone > wants to read out, etc) and, even more obviously, they have significant > problems. It just seems to me that we're trying to address the issue of > wanting nice looking text with a very specific solution on one element. > Maybe we should consider what we could do across the platform? > Canvas is somewhat different from the rest of the web platform. Since most DOM rendering is essentially retained mode, you always have the option to decide at render time whether or not to use subpixel antialiasing, or to re-render a previously-rendered buffer when necessary (and Chrome and Safari already do this). Since Canvas is immediate-mode, you don't have that option. If a canvas is drawn once, then later rotated via CSS, the "is LCD text legal" probe is now stale. That said, using the opaque attribute (or alpha:none) doesn't completely solve this either. It only guarantees that at least subpixel AA text within the canvas itself will not fringe. There's no guarantee that it won't when transformed via CSS (or WebGL) later. As you point out, the fully-automatic solutions to those problems (which have been discussed over on whatwg) themselves have unpleasant performance implications, or complexity of implementation, and don't entirely solve the problem either (e.g., canvas->WebGL). My preference is actually for a canvas context attribute which enables subpixel antialiased text unconditionally. It makes no promises at all about immunity from color fringing, but gives the power to the developer (a fully-loaded footgun). Native immediate-mode graphics APIs have this capability, so it seems natural to provide the same power to the web platform, IMHO. But let's continue that discussion on whatwg, since it's not specific to WebKit. Stephen > > Dean > > > > So, the canvas has to be blended if there's alpha. There's no magic > getting around that. The only way around it is to give the user a way to > say "no alpha". > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
