Sorry for the long delay. (In reply to comment #25) > You're correct that PangoCairo is not used, except on BeOS. We'd love to use > it, but aren't in a position to do so due to the requirements it has. We'd > love for those requirements to change so we can use it. > > Specifically, last I checked PangoCairo needs pango 1.10 or higher. See bug > 305649 comment 8. For reference, FC4 ships with pango 1.8. FC3 shipped (as > recently as end of 2004) with pango 1.6. Our current code (using CairoXft) > requires pango 1.6, which is still a huge jump in requirements over what we > require for Gecko 1.8, but we're _really_ not in a position to require that all > of our Linux users upgrade to FC5 or newer. Well, pangocairo is as old as cairo itself, and requires a pango version of the same age. It may be possible to use pangocairo with older versions of pango if someone does the job of backporting it, but from the upstream point of view, pangocairo is part of the pango distribution and released with pango. there have been three stable versions of pango shipping with it now: 1.10, 1.12, and 1.14. I would argue that by the time that Firefox want so ship with pangocairo, FC5 is not such a huge requirement. Earlier Fedora versions don't have cairo either afterall. I know mozilla currently has its own cairo copy, but isn't the plan to remove that and use upstream when all the patches are merged (almost there)? > If you can make PangoCairo work with pango 1.6, we should be able to use it, > and that would be very nice. If it requires 1.8, we can at least think about > it.... But the current runtime requirements of PangoCairo simply make it > unusable for our purposes. So we've had to work around that by using PangoXft > for fonts, with resulting problems all around. So, if I understand it correctly the code paths in question use Pango unconditionally, right? In the Firefox 1.5 series that Pango is optional, requiring pangocairo is not such a big deal I assume. Anyway, basing your future rendering on the cairo+pangoxft set of libraries doesn't sound right to me. Also, about the patch in this bug, it will make a difference in rendering of Latin. Pango now enabled OpenType Layout processing for Latin fonts. This means, the Xft measurements don't take into account things like ligatures, while the pango path does. (In reply to comment #26) > I would suggest that it's not a very strong position to jump in to a thread > with "I confess I'm totally lost." and then follow up with a "No, you don't get > it.", but that's perhaps a style choice. I didn't know that expressing my confusion may be offensive. Put it on me being totally shocked. > I think it's a good time to reiterate something that's been mentioned several > times in this thread, including once when specifically asked: the intention was > to avoid using Pango. > If the gripe was "yes, but you're still (mis)using a piece of API", then > perhaps something more constructive could have been added to this bug. Yet even > if that were the case, the point of this patch has been missed completely > since, *obviously*, that all could have been implemented (and has been!) with > purely fontconfig & Xft calls. It turns out it's faster and more interesting in > the short term for several reasons to use the same code paths that the other > Pango code is eventually forced to use. After all, this optimization is a > *special case* for only a few languages. But even for those few languages, it makes a difference. For 'ff', 'fi', 'ffi', and similar ligatures that many decent fonts have. > If this "design" still bothers you, > consider it an work-in-progress experiment. Ok. > Instead, the post went out of its > way to say "I won't comment" and "I won't make it faster". > I'll have to assume this is in reference to > http://bugzilla.gnome.org/show_bug.cgi?id=348825 I said: "I can't and won't spend time making it faster as all my focus is in PangoCairo". I don't think that needs more explanation. And this is not in response to any other bug. Chris Aillon sent me this bug after seeing I'm working on making firefox+pango faster. > the cache-miss-as-norm > behavior of the fontset cache that is very clearly exhibited with with the > slightest experimentation (You've done some right? How is that sorting several > times per page going?). You know that I'm working on that problem and have already increased the cache size for example. > If this is the case, the hostile attitude is very unfortunate for users of > Pango, especially obscure corner cases like, you know, web browsers. Which hostile attitude? That my focus is on pangocairo? > It's especially important to remember that this particular cache is the very > same cache that misses many times per page load *using* PangoCairo, which > impairs page load times even WITHOUT drawing a single string. "WITHOUT drawing a single string" doesn't mean much, as measurement and layout is harder than drawing. > Additionally, > pango_shape also stands way out. So, it turns out you're right in that point > that I was NOT enjoying the optimization work done last fall! pango_shape is very hard to optimize. Most of the time it takes (in pango >= 1.12) is in the Open Type code. > So, one more time, there are performance wins because this patch largely > *avoids* using Pango to measure. It's an unfortunate side note that it was only > after this that a comment on Pango performance was made from someone working on > Pango. What is surprising though, is that no one ever reported any bug about "pango is slow for firefox in here and here" earlier than this past July (ie, three months ago.) > Since I'm such a glass-is-half-full type, I see this as a great opportunity for > rapid improvement, at least for users on future platforms! Agreed. So, what should I do? Open a bug "please use pangocairo"?