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. behdadReceived on Monday, 9 July 2012 03:03:04 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:18 UTC