[whatwg] Enabling LCD Text and antialiasing in canvas

[Stephen White]

On Tue, Jul 16, 2013 at 6:41 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> This thread was gigantic and involved many proposals. I've only included
> the last one below, since it seemed to take into account the most of the
> feedback mentioned on the thread; I haven't responded to all the
> intermediate e-mails which were mainly just a discussion amongst
> contributors, and not direct feedback on the spec itself.
>
> I haven't yet changed the spec. The main thrust of the feedback below ends
> with the proposal to use WebGL's 'alpha' feature for the 2D context; is
> this what implementors want to do?
>

We're implementing this in Chromium (currently behind the "experimental
canvas features" flag).


>
>
> [...]
>
> On Fri, 15 Feb 2013, Stephen White wrote (with roc's annotations inline
> prefixed with | and mine inline not prefixed):
> >
> > So let me take a stab at a brief summary of the proposals so far, and
> > the pros and cons of each (correct me if I missed anything):
> >
>   opaque attribute or matteColor property
> > pro:  fairly easy to implement
> > pro:  no performance hit over regular rendering
> > pro:  many opportunities for optimization
> > pro:  catches all in-canvas cases of color fringing
> > con:  does not handle any out-of-canvas color fringing
> > con:  opt-in
> | con:  requires changes to canvas compositing spec and possibly
> |       implementations.
> >
> > automatic opacity detection
> > pro:  catches most (all?) cases of in-canvas color fringing
> > pro:  some opportunties for optimization (must be conservative in some
> >       cases)
> > con:  does not catch color fringing on CSS transforms, canvas -> WebGL,
> >       etc
> >
> > context.textAntialising = { 'none', 'grayscale', 'subpixel' }
> > pro:  very easy to implement
> > pro:  no performance hit
> > con:  does not catch any cases of color fringing; completely up to web
> >       developer
> > con:  opt-in
> | con:  requires specification and implementation of what happens when
> |       subpixel AA is drawn over transparent background.
> >
> > collect commands into a buffer, flush buffer only when compositing
> > canvas to page, and decide on subpixel AA at that point.
> > pro:  catches all cases of color fringing
> > con:  in some cases, requires an infinite buffer (e.g., a canvas that
> >       never clears, and only accumulates drawing frame-to-frame means
> >       you must accumulate commands indefinitely)
>         or giving up and using grayscale at some point
> > con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
> > con:  may introduce performance hit due to re-rendering with and without
> >       subpixel AA (in cases where you would rather have just gone
> >       without)
>   con:  doesn't handle pixel manipulation cases (since you can't return
>         two sets of pixels and you can't regenerate the stuff that script
>         is generating based on the returned pixels)
> >
> > two buffers (one grayscale, one LCD AA)
> > pro:  handles all cases of color fringing
> > pro:  moderately easy to implement
> > con:  RAM (or VRAM) usage is doubled
> > con:  possibly-unnecessary performance hit
> > con:  must be opt-in
>
> [...]
>
> On Wed, 20 Feb 2013, Rik Cabanier wrote:
> >
> > So now we have:
> > - don't do this on pinch-zoom devices
> > - don't do this for HW accelerated canvases
> > - don't do this if the canvas dpi doesn't match the screen
> > - don't do this if there are transforms
> > - authors will have to be very careful when using this feature since it
> can
> > turn on or off or cause rendering glitches.
> >
> > Is it still worth pursuing this?
>
> On Thu, 21 Feb 2013, Stephen White wrote:
> >
> > I believe it is.  Even with those constraints, there are a large number
> > of applications which can benefit from text which looks as good as the
> > native platform can provide.
> >
> > That said, I also think Robert is right that we should not spec out
> > precisely when subpixel AA text will occur in any of these automatic
> > modes, since:
> >
> > 1) there are some platforms/devices which don't do LCD text at all
> >
> > 2) It may be too restrictive for the browser implementor, e.g., they
> >    may be essentially required to implement deferred rendering or two
> >    backing stores in order to meet the resulting spec, which seems
> >    onerous
> >
> > Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque,
> > if only just for the optimization opportunities that we don't get with
> > an automatic solution (e.g., putImageData).  Its implementation is
> > fairly straightforward (much more so than the other options above), and
> > it won't break any existing content.
> >
> > To me, the "it breaks compositing" argument falls into the "doctor, it
> > hurts when I do this" category:  the user is specifically opting into an
> > opaque backing store, and so the changes in behaviour for compositing
> > modes which reference destination alpha are expected, just as they are
> > when using DST_ALPHA blending modes in a WebGL context created with the
> > "alpha" attribute set to false.
>
> On Fri, 22 Feb 2013, Robert O'Callahan wrote:
> >
> > I think Rik is convincing me that we shouldn't expose mozOpaque or any
> > other explicit subpixel AA control to the Web. It will be very easy for
> > Web authors to test it in one place and discover that it works without
> > realizing that they're causing problems for some users.
> >
> > I think a fully automatic solution that tries to use subpixel AA but is
> > always able to render grayscale AA if needed is the way to go. Possibly
> > with an author hint to suggest opting into a more expensive rendering
> > path.
>
> [...]
>
> On Wed, 13 Mar 2013, Gregg Tavares wrote:
> >
> > Sorry for only mentioning this so late but is there any chance to steer
> > this to be more inline with WebGL?
> >
> > WebGL already has the option to have an opaque canvas using context
> > creation parameters. In WebGL it's
> >
> >    gl = canvas.getContext("webgl", {alpha: false});
>
> [...]
>
> On Fri, 19 Apr 2013, Stephen White wrote:
> >
> > Here's a short proposal I've written up for the getContext('2d', {
> > alpha: false } ) version of this idea (much of it culled from the
> > mega-thread above).
> >
> > http://wiki.whatwg.org/wiki/CanvasOpaque
>
> Seems reasonable; who is implementing this?


We're implementing this in Chromium (currently behind the "experimental
canvas features" flag).


>
> On Wed, 13 Mar 2013, Gregg Tavares wrote:
> >
> > But, there are other context creation attributes we'd like to see on a
> > 2d canvas. One that comes to mind is 'preserveDrawingBuffer'.
> > preserveDrawingBuffer: false in WebGL means that the canvas is double
> > buffered. This is a performance win since most browsers using GPU
> > compositing need to copy the contents of the canvas when compositing.
> > Setting preseverDrawingBuffer: false (which is the default in WebGL)
> > means the browser can double buffer and avoid the copy. We'd like to see
> > that same attribute for 2D canvas/contexts to get the same perf benefit
> > for canvas games, etc.
> >
> > So, given we want more creation attributes and given WebGL already has a
> > way to declare opaqueness why not follow the existing method and add
> > context creation parameters to 2d canvas to solve this issue rather than
> > make a new and conflicting 'opaque' attribute?
>
> 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"
> >
> > [...]
>
> How about these, is anyone interested in implementing these?
>

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.

Stephen


>
> On Tue, 12 Mar 2013, Stephen White wrote:
> >
> > As an example, the "darker" compositing mode was removed from the spec
> > due to hardware-accelerated performance concerns, IIRC.
>
> No, it was removed because it had no spec.
>
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>