On Thu, Mar 14, 2013 at 1:38 PM, Ryosuke Niwa <[email protected]> wrote: > On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson <[email protected]> wrote: >> >> >> On 15/03/2013, at 6:50 AM, Dana Jansens <[email protected]> wrote: >> >> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
