Tuesday, 3 July 2007

Text Status

Time for a quick update on textframe status... The new textframe was turned a couple of weeks ago. There have been some regressions, but I've fixed the big ones, I think. There was a small but significant Tp win (around 5% depending on platform).

Today I checked in a followup patch that fixes a few issues with soft hyphens (­). They should basically work now. That's good news for us and for the Web.

Other than just fixing regressions and other bugs, there are a few followup issues I want to address before beta 1, or possibly after it:

  • CVS remove nsTextFrame
  • Remove nsTextTransformer, which is almost entirely unused now
  • Remove other unused support code from nsLineLayout and elsewhere
  • Reland changes to nsILineBreaker implementation that have it use Pango on Linux
  • Work on my patch to get and cache accurate glyph bounds
  • Figure out what our story is going to be on quality vs speed

The last item's a tricky one. Currently on Windows and Linux we have a "fast path" for Latin-1 text rendering that avoids Uniscribe/Pango, disabling ligatures (and kerning too, on Linux). It would be nice to have ligatures and kerning on, but going through Uniscribe and Pango for everything would be a significant slowdown. (On Mac we're currently going through ATSUI for everything; we could add a Latin-1 fast path if we want to, in which case these considerations would apply to Mac too...) Here's my current thinking:

  • Text in chrome documents should default to optimizing for quality. We hardly ever need to layout massive quantities of text in chrome. Also some system fonts on Vista really want ligaturization.
  • Text in content documents should default to optimizing for speed, for benchmarks and users with slow machines.
  • But users, especially users with fast machines, should be able to opt for quality.
  • Perhaps if we dectect the user has a fast machine, we could set them up for quality by default.
  • We could also give authors control over quality, perhaps by using the SVG text-rendering CSS property.

This needs thought and wider discussion.


  1. How much slower is it with a really new Pango and Cairo, say on Ubuntu Gutsy?

  2. Hmmm. Now that we finally, after all those years, have darn nice text display on the Mac, I'd vote for quality :-)
    I understand the need or concern for speed, though. Currently Gecko Mac is a bit slow... But I don't think text is the main performance issue. And Vlad's latest Cairo update improves things a lot.

  3. Me too. And if there will be a setting in the future, I hope that quality will be the default.
    And it's not just text that needs it. Images also needs the same treatment with ColorSync support, better upscaling (downscaling is already better in FF 3.0), ...

  4. Robert O'Callahan3 July 2007 at 22:30

    Ernst: We don't know.
    Philippe: Text is still a major component of performance on many pages.

  5. Ever thought of bouncing off these ideas at the TextLayout summits?

  6. Robert O'Callahan5 July 2007 at 04:47

    Yes, but I've never been able to attend a TextLayout summit.

  7. Philippe, profiles say that text measurement is in fact one of the top layout performance bottlenecks. Always has been. On a typical web page, something like 25% of the layout time is spent there. On a text-heavy page, that number can be higher. That's with the current (fast) text measurement. When it was slow, in the past, it was a lot worse.

  8. Have you seen http://antigrain.com/research/font_rasterization/ ? The summary is you get great looking text by using high-resolution (1/256 pixel) advance and kerning values. Is this something to be solved at the application (Mozilla) layer, or is it a cairo, pango or freetype problem?

  9. Robert O'Callahan12 July 2007 at 10:17

    Interesting page.
    To get that to work on Windows and Mac we'd have to ship Freetype I think.