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

[Dean Jackson]

On 15/03/2013, at 7:45 AM, Kenneth Russell <kbr at google.com> wrote:

> On Thu, Mar 14, 2013 at 1:38 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson <dino at apple.com> wrote:
>>> 
>>> 
>>> On 15/03/2013, at 6:50 AM, Dana Jansens <danakj at chromium.org> wrote:
>>> 
>>> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson <dino at apple.com> wrote:
>>>> 
>>>> I'm not sure I like this proposal. Why is canvas special? Why doesn't
>>>> <img> get an opaque attribute (or flag)? Why not every element?
>>> 
>>> 
>>> There is ongoing work to infer opaqueness in every other kind of element
>>> when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634
>>> 
>>> 
>>> Yes, I'd prefer to infer it rather than specify it. For example, I could
>>> infer that a canvas is opaque if it has a non-transparent CSS
>>> background-color.
>> 
>> 
>> I like this approach. It means that developers don't have to explicitly use
>> this feature to get the performance benefits.
>> 
>> In fact, this is the preferred performance optimization approach on the Web.
>> We don't provide explicit APIs to optimize performance. We make sensible
>> APIs which allows us to implement more optimizations on common cases behind
>> the scene.
> 
> Not to put words in Stephen's mouth, but as I understand it, the main
> reason for adding this attribute is to enable higher-quality,
> LCD-antialiased text on canvases.
> 
> Without it, it's impossible (or, at least, very difficult and low
> performance) to infer whether it's legal to use LCD antialiasing. Most
> ports' Canvas 2D implementations are GPU-accelerated, and it would be
> necessary to test all pixels underneath the text to ensure they are
> fully opaque before drawing the text. This would require a readback of
> the canvas's contents from the GPU, which would perform very poorly.

Yes, we get complaints about this all the time. But it seems to reenforce
my point that canvas is not special here. I expect more text to be 
rendered in non-canvas elements than canvas, and those elements could
be GPU-accelerated as well (they often are on Apple platforms).

However, your point does mean that simply testing the CSS background-color
will not work in all cases. For example, drawing a canvas into another
canvas. But in that case, unless you're drawing 1:1 and on a pixel boundary,
your subpixel antialiasing is going to be screwy anyway.

Dean