On Thu, Mar 14, 2013 at 4:38 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson <d...@apple.com> wrote: > >> >> On 15/03/2013, at 6:50 AM, Dana Jansens <dan...@chromium.org> wrote: >> >> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson <d...@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
