Monday 2 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.
Comments
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.
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), ...
Philippe: Text is still a major component of performance on many pages.
To get that to work on Windows and Mac we'd have to ship Freetype I think.