[whatwg] Enabling LCD Text and antialiasing in canvas

[Ian Hickson]

On Sat, 24 Nov 2012, Adam Barth wrote:
> On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 12 Nov 2012, Justin Novosad wrote:
> >> For many types of apps, DOM-based rendering is uncompetitively slow 
> >> [so we should make text rendering in canvas more controllable]
> >
> > This seems like something we should fix, not something we should work 
> > around by having people use canvas instead. Using canvas has all kinds 
> > of terrible side-effects, like reducing the likely accessibility of 
> > the page, making searcheability much worse, etc.
> 
> The metrics I've seen show that the magnitude of this problem is 
> approximately 8x (to the extent that it's sensible to represent the 
> magnitude with a number).
> 
> As far as I can tell, the issue really boils down to the DOM being 
> retained mode and canvas being immediate mode. [...snip a very lucid 
> explanation of why some people end up using canvas when they are 
> writing an app that has a large underlying model, even if their output 
> has little to do with graphics per se]
>
> I think the real question here is how do we want applications with very 
> large models to render?  Do we really want them to upload their entire 
> models into DOM?  If not, how can we provide them with a high-quality 
> immediate model rendering pipeline.

I don't think "the DOM" and "a bitmap API" are the only points on the 
spectrum that we should discuss here.

Using canvas (2D or GL) to generate a traditional app (i.e. not a game) is 
a disaster. Here's a brief list of the ways doing this would suck:

Platform-native look and feel of widgets has to be reimplemented.
Platform-native accessibility bindings have to be reimplemented.
Platform-native scrolling behaviour of scroll areas have to be 
reimplemented.
Mouse placement of text carets has to be reimplemented.
Keyboard movement of text carets has to be reimplemented (possibly across 
lines, for multiline text input).
Scrolling of text fields has to be implemented (horizontally for long 
lines, vertically for multiline input).
Native features such as copy-and-paste have to be reimplemented.
Native features such as spell-checking have to be reimplemented.
Native features such as drag-and-drop have to be reimplemented.
Native features such as page-wide text search have to be reimplemented.
Native features specific to the user, for example custom text services, 
have to be reimplemented. This is close to impossible since each user 
might have different services installed, and there is an unbounded set of 
possible such services.
Bidirectional text editing has to be reimplemented.
For multiline text editing, line wrapping has to be implemented for all 
relevant languages.
Text selection has to be reimplemented.
Dragging of bidirectional text selections has to be reimplemented.
Platform-native keyboard shortcuts have to be reimplemented.
Platform-native input method editors (IMEs) have to be reimplemented.
Undo and redo functionality has to be reimplemented.
Accessibility features such as magnification following the caret or 
selection have to be reimplemented.


IMHO we should provide an API that addresses these needs while providing 
the performance of a non-DOM-backed immediate-ish mode API. It's not 
canvas. I'm not sure what it is, exactly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'