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

[Kenneth Russell]

On Thu, Mar 14, 2013 at 1:55 PM, Dean Jackson <dino at apple.com> wrote:
>
> 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.

Yes, there are many caveats about enabling LCD antialiasing in the
canvas API. I haven't followed the discussion on the whatwg mailing
list completely, but I think that most of the issues have been
discovered.

-Ken