(In reply to comment #38)
> I appreciate it if you point me to benchmarks such that I can reproduce the
> 500%.

Sure.  Take trunk builds from before the patch for this bug landed, both cairo and non-cairo.  Load the testcases in bug 64858.  You might need to edit out the JProfStartProfiling/JProfStopProfiling calls unless you're actually profiling with jprof.  Look at the reported times.  I get about 4x better performance with the non-cairo builds, with the vast majority of the time difference being text measurement performance.

As Robert said, a lot of this is impedance mismatch between what pango wants to do and what current trunk is trying to get it to do.  But that doesn't help the fact that right now trunk was unusable for daily browsing.  The more text, the less usable.  Once we rearchitect our layout code around what pango and such want, we'll have to remeasure, of course; at that point we should revisit the changes made in this bug.

>  The Pango-based Firefox shipped in Fedora is definitely not 500% slower.

I can't speak to what changes Fedora made and what they use pango for.  Our real concern is trunk going forward.

> Is it?  http://www.mozilla.org/projects/firefox/roadmap.html says "Q1 2007?",

That would be in like 3 months.  I'm giving it some slack here.  ;)

> Release".  Do you expect me to believe that page?

Not at all.  I don't believe it myself.   ;)

> I'm not.  I'm just a developer.  If you expect someone like me to fetch and
> compile the developmental Firefox versions

When have I ever asked you to do that?

> (which takes a one or two gigs)

Non-debug builds don't one or two gigs...  And those are all you need for optimization (profiling) purposes.  But that's neither here nor there.

> why can't Firefox developers install a three tiny
> libraries that are glib, cairo, and pango?

In brief, because the package systems on Linux suck.  For example, I can't install an updated pango without updating hundreds of other packages, due to the RPM dependency mess.  Worse yet, users would have to have the updated pango too, which means either the distros need to ship it or we need to.

> You can ship with internal copies of glib and pango and gtk+.

We could, but that's something we'd like to avoid.  Given that all the paths forward seem to suck, we're going to got with what we see as the lesser evils.

> That's such a bold statement.  Do you have any benchmarks?  I'm very
> interested in checking them out.

See beginning of this comment.

> If you, a developer, need to upgrade your OS first to get a non-ancient
> Pango,

I'm not a pango developer.  I'm a pango user.  I'm developing on my own machine, part-time, and the machine is used for a whole lot of things other than Firefox development.

> why do you think all your users install Firefox on ancient operating systems?

First of all, a year old is not exactly ancient.  Second of all, when did I say "all"?  I'm not saying all Linux users use FC3 or FC4 or equivalent.  I'm saying not all use FC5.  Please don't put made-up words in my mouth.

> Suppose that I backported pangocairo to work with pango-1.8.  How are your
> users going to get that pangocairo library? 

Like I said, "that are actually shipped to an overwhelming majority of Linux users".  You clearly can't control that, but if there's an option to do it we could work with distros to ship such updates.  Right now, all distros can tell us is "can't do that".

Carl, I don't think anyone's asking Behdad to spend significant time optimizing parts of pango that he considers deprecated.  But then I'm not sure why he's being so defensive about us trying to avoid those parts of pango....