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

[Stephen White]

On Thu, Mar 14, 2013 at 4: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.
>

The problem is, automatically determining opacity automatically may itself
incur a performance hit.  For example, it would be impossible to determine
if putImageData() was going to result in an opaque canvas without
inspecting each pixel.  By simply describing the use case and constraints
up front, you allow the user agent to optimize what it could not otherwise
do.

The problem is compounded for subpixel antialiased text, where determining
automatically when it is safe to use can require double the memory or VRAM,
and  potentially double the rendering time, due to canvas being an
immediate mode API, rather than retained mode like most of the rest of the
DOM.  See
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038958.html.
 For that reason, it would still require an opt-in in order not to impact
the performance of existing pages.

At any rate, I appreciate your feedback, and welcome you to contribute to
the whatwg thread.

Stephen

>
> - R. Niwa
>
>
> _______________________________________________
> 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/84680449/attachment.html>