On Thu, Mar 14, 2013 at 1:55 PM, Dean Jackson <[email protected]> wrote: > > On 15/03/2013, at 7:45 AM, Kenneth Russell <[email protected]> wrote: > >> 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. > > 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 _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
