Comment 106 for bug 32561

Revision history for this message
In , Mwsteele (mwsteele) wrote :

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 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. If this "design" still bothers you, consider it an work-in-progress experiment. 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 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?).
If this is the case, the hostile attitude is very unfortunate for users of Pango, especially obscure corner cases like, you know, web browsers.
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. 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!
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.
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!