Comment 41 for bug 32561

Revision history for this message
In , L. David Baron (dbaron) wrote :

In a few days of using Cairo builds, I've noticed that, despite bug 333251's dependencies being fixed, the builds are still unusably slow on many Web sites.

It probably doesn't help that I have a lot of fonts installed (see below) -- basically all the truetype font packages that come with FC5, plus a few others.

One example of this is the following steps to reproduce:
 1. load http://www.mozilla.com/ in one tab
 2. load http://www.mozilla.com/firefox/all.html in another tab
 3. switch between the tabs using Ctrl-PgUp/PgDn

It takes a few seconds to switch from tab to tab.

A realtime jprof profile (which includes some idle time) shows that:
 * 76% of the time is spent painting
   + presumably mostly the HTML documents
 * 13% of the time is spent reflowing
   + entirely the XUL document for the browser

 * 82.5% of the time is spent within gfxPangoTextRun::EnsurePangoLayout
   + this happens both during painting and reflow
   + 64.5% of the total time (78% of EnsurePangoLayout) is in FcFontSort
 * 11% of the time is spent within XftLockFace
   + all of that is within painting

So I'd make the observation that there are at least two dependencies to making this perform acceptably:

 1. fixing whatever rearchitecture needs to happen so that we don't need to redo all of this work for every paint

 2. porting bryner's work in bug 223813, which avoids unneeded calls to FcFontSort (plus followup regression fixes, of course), to whatever's doing our interaction with fontconfig (currently pango)

I'm switching back to non-cairo builds because of this, and I seriously question whether cairo should be turned on for our GTK2 builds as long as these performance problems are present.