[whatwg] Enabling LCD Text and antialiasing in canvas

[Ian Hickson]

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?


[...]

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?


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?


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.   `._.-(,_..'--(,_..'`-.;.'