21 Oct 2005 freetype   » (Master)

Pango, Text Layout and UI Performance

Kudos to Federico for starting to optimize Pango. I know fom experience that even a small performance difference in text layout alone (i.e. without touching glyph rendering) has a huge impact on user's perceived interface speed. That's because toolkits and applications tend to draw a _lot_ of text, even when they could trivially avoid it.

When I had to add Arabic to my company's products, the text layout operation timing initially doubled due to the support of the Unicode BIDI algorithm. It was a custom solution since we couldn't use either ICU or FriBidi. I didn't think it would be a big issue since, in the graphics architecture we were using back then, the time to transfer text glyphs to the screen was very important. My own tests didn't show any perceivable difference anyway when the whole application was running.

Well, I was wrong. It turned out that the application could switch dynamically between English and Arabic presentation mode, and the client complained that scrolling lists in Arabic was slower than in English. How much slower ? Well, a really _tinsy_ bit slower, you had to scroll several pages on the list to really show the difference. But they were horrified by this and considered this to be a top-priority issue.

After a quick analysis, it turned out that:

  • the list component redraw the whole page everytime you went from one item to the next, even though it only needed to update two lines

  • due to the component's design, this required a rewrite, and there was no time to do that (different team, different planning, etc..)

I ended up rewriting the BIDI implementation and the Arabic shaper, with all kinds of tricks. It's probably a bit slower than ICU's algorithm (which is insanely clever, by the way), but at least I knew it would be manageable by someone other than me at the company ;-)

The end result was that laying out Arabic text is now only 10% slower than English in our product, mainly because we don't use OpenType fonts !!.
Problem solved. Except we're probably never going to fix the list component. Ah ah...

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!