On Sun, Jul 8, 2012 at 8:48 PM, John Daggett <jdaggett@mozilla.com> wrote:
>
> One of the underlying differences in text performance is not the
> actual time needed to deal with kerning data for example, but the fact
> that the "plain text" code uses a very simple API call that's been
> tuned and the "typographic mode" code uses a catch-all API that
> handles *all* complex text and hasn't been tuned nearly as much. The
> bottom line in the kerning case is that once you're pulling glyphs and
> advances from font data, also pulling the kerning pairs is a very
> small delta on top of that. There's a bit of a catch-22 situation
> here, since the complex text path is used infrequently there's much
> less incentive to optimize it. It also ends up generally having more
> bugs, because certain features are tested with the "plain text" path
> and not the complex text path (see [1] for an example).
This definitely is the case currently, and something I have been wanting to
see change for quite a while. Firefox has shown us that complex text
shaping by default does not have to be expensive. It's just yet another
cache... It is my aim to eventually address that in Chrome, but the spec
requiring that behavior will surely give vendors more incentive to do the
Right Thing.
behdad