356695 - Patch for bug 356235 caused a Tp regression on Linux

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Adam Guthrie]

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.

Comment 1

[Adam Guthrie]

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

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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