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

[Kenneth Russell]

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.

-Ken