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

[Stephen White]

On Thu, Mar 14, 2013 at 5:23 PM, Dean Jackson <dino at apple.com> 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.
>
> 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130318/85cea731/attachment.html>