690 MOZ_CO_DATE=2006:10:14:00:08 747 MOZ_CO_DATE=2006:10:14:00:46 Checkins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006%3A10%3A14%3A00%3A08%3A00&maxdate=2006%3A10%3A14%3A00%3A46%3A00&cvsroot=%2Fcvsroot Definitely a regression from bug 356235.

For what it's worth, this patch hurt Linux about as much as it helped Windows (-/+ 0.9%).

I think that the cache mechanism will win on intl text rendering. On the case we need to itemize and reordering (if Bidi text) the items the string. But maybe it is expensive. So, if we cache the itemizing data, we might get the great performance. But the ASCII text rendering case is not so... And I have a question. Should we merge the gfxXftTextRun and the gfxPangoTextRun? If the string doesn't have complex text, we don't need to use itemizing and shaping of pango. And it might be simpler for cache mechanism.

The question is whether this cache will still be useful once textframes keep a pointer to their textrun.

This will probably go away with the new textrun code; also the Tp numebrs seem back to normal even with the cycle collector by now... so this is probably invalid at this point, but it should be easy enough to test.

This code has drastically changed by now; new textframe should've fixed the issues.