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

Stephen White senorblanco at chromium.org
Wed Apr 3 09:08:25 PDT 2013

For reference, here is a prototype patch which implements <canvas opaque>:
And one which implements getContext('2d', { alpha: none }):

I believe this represents the bulk of the cross-port work that would be
required; there is further port-specific work required, but this should be
mostly in platform/graphics/*.


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?
> 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/20130403/2bce5913/attachment.html>

More information about the webkit-dev mailing list