This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On Tue, 23 Jul 2013, Stephen White wrote: > On Tue, Jul 16, 2013 at 6:41 PM, Ian Hickson <ian@hixie.ch> wrote: > > On Fri, 15 Mar 2013, Gregg Tavares wrote: > > > > > > What about a context attribute "antialiasRenderingQualityHint" for now > > > with 2 settings "default" and "displayDependent" > > > > > > context.antialiasRenderingQualityHint = "displayDependent" > > The Chrome team would like to implement this, although I'd like to bikeshed > on the name a bit. :) Something like: ctx.fontSmoothingHint (to match > ctx.imageSmoothingEnabled) with values "none", "antialiased" and > "subpixel-antialiased". Or if we must have a two-state, just a "true" / > "false" boolean, where false = default behaviour, true = subpixel-AA (where > available). "displayDependent" is just confusing, IMHO. Putting "Hint" in > the attribute name should be enough to convince people it's not a firm > commitment.
Any interest from vendors other than Chrome?
Where's the context? I don't know of any use-cases for "none". Subpixel-AA should often be disabled due to environmental factors (e.g. pinch-zoom is enabled and the browser renders stretched canvas bitmaps during pinch-zoom). So we probably wouldn't want a value which purports to force-enable subpixel-AA. There's also the question of how this value would interact with transparent canvas bitmaps and the author drawing text over transparent parts of the bitmap. So it's not clear exactly what the use-cases and intended semantics are here.
I filed the bug because a vendor said they wanted to implement. These are some relevant(ish) threads on which this topic was discussed: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg124 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/thread.html#msg62 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/thread.html#msg77 http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/thread.html#msg3 The first e-mail says: | The main motivation is to make web apps better. For many types of apps, | DOM-based rendering is uncompetitively slow (e.g. rendering a large number | of independently positioned text labels). On the other hand, 2D canvas can | deliver significantly better performance in many cases, but there is a | degradation in visual quality due to the lack of LCD text filtering. | Current browsers don't enable LCD text in 2D canvas to prevent rendering | artifacts. If LCD text were enable-able, authors would have to be mindful | of a number of caveats in order to avoid rendering artifacts. For example, | artifacts could result from certain use cases of canvas compositing, | transforms on the canvas element, canvas-to-canvas copying with drawImage | with a transform applied. These are the same caveats native app developers | must face when using LCD text filtering. ...however, that particular rationale IMHO argues for something quite different: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0082.html In the very next e-mail, you argue for opaque canvases instead: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0152.html ...which are covered by bug 23515. IMHO there is no compelling rationale that has currently been put forward for the feature requested in comment 0.
OK, some of this is coming back to me now... I think the best idea there was for the implementation to keep two canvas buffers, one with subpixel AA and one without. Then it can render whichever buffer is appropriate, i.e. render the subpixel-AA buffer whenever canvas pixels are being mapped directly to screen pixels. Because this will be slower and use more memory, I think it makes sense to have a boolean canvas attribute, e.g. "enableSubpixelAntialiasing", to let authors opt into this behavior. Alternatively we could have no API and just let browsers do it automatically when the canvas is opaque and other heuristics are satisfied. But I think an attribute is justified in this case.
When the canvas is aligned 1:1 with device pixels, and the canvas is opaque (created with the {alpha: false} options), we are in a condition where it is safe to use subpixel text anti-aliasing without worrying about compositing artifacts. Both Firefox and Chrome have solved this issue by automatically enabling sub-pixel text AA when these conditions are met. This behavior is undocumented in the spec since the spec remains agnostic with respect to anti-aliasing. Is the current technical solution good enough? Perhaps we could just add a non-normative note in the spec to suggest this behavior near the definition of the 'alpha' option?
I guess per comment #4 the suggestion is to allow authors to opt in to a slower mode, even with non-opaque or non-aligned canvases. Do you think that's worthwhile?
It is not clear whether that is needed. The feedback I got from the Google Sheets team (they use canvas for the cell grid) is that they are satisfied with the status quo.
OK. I guess this can be closed then, although a note might be good. I'm not sure what a note would say exactly; "in some implementations; pixel-aligned opaque canvases have text antialiasing applied" or something? Seems kinda un-speccy.
I think something along the lines of what Justin said might be good. Note: If canvas pixels are 1:1 with device pixels and the canvas is opaque (i.e., alpha is false), implementations can, and are encouraged to do so, use sub-pixel text anti-aliasing. This is non-normative as for now the HTML standard stays clear of requiring particular anti-aliasing behavior.
See https://github.com/whatwg/html/issues/2854.
Closing this as WORKSFORME since the specification already allows for anti-aliasing and we decided above no new feature is needed for this.