Performance loading http://www.w3.org/2006/11/W3C10/ja/ has become unacceptably slow on the trunk on Linux. This is a regression between 2006-11-20-04-trunk and 2006-11-21-04-trunk . This performance is slow enough that it blocks testing, and I think the offending checkin should be backed out if it cannot be fixed promptly. The most likely cause seems to be bug 352174. Steps to reproduce: * load http://www.w3.org/2006/11/W3C10/ja/ Actual results in 2006-11-21-04-trunk and a debug build from yesterday: * page takes about 55 seconds to load, and the browser is locked up most of that time * page takes about 8 seconds to repaint if the window is covered by another one and then exposed again * tons of: (Gecko:4143): Pango-WARNING **: Error loading GPOS table 4097 are printed to the console. Expected results (as observed in 2006-11-20-04-trunk): * page loads in 2-3 seconds The problem also seems to be present on http://www.tokyometro.jp/index.html I'm using Fedora Core 6.

Oshima-san and taken-san: Can you reproduce this slow rendering?

Do you have the japanese font package (fonts-japanese.noarch) installed? I was seeing performance problems with missing fonts.

Yes, I have fonts-japanese (and pretty much all the other vector fonts that come with Fedora) installed.

I see what happens. the computed value of the paragraph is "font-family: Gill Sans MT,Gill Sans,GillSans,Verdana,Lucida Grande,Lucida Sans,Lucida Sans Unicode,sans-serif;" on http://www.w3.org/2006/11/W3C10/ja/ . Do you have "Gill Sans MT"? If you don't have this font, the font name resolver doesn't work fine by bug 362048. Note that the current Itemizing rendering is too slow, but maybe it will be fixed by the new text frame of roc.

(In reply to comment #5) > Do you have "Gill Sans MT"? If you don't have this font, the font name resolver > doesn't work fine by bug 362048. No, I don't have the font.

The patch in bug 362048 doesn't help, though. (I just applied the one change at the beginning of gfxPlatformGtk::ResolveFontName to initialize aAborted to PR_FALSE.)

O.K. I think that this bug is an issue of Itemizing function performance. Now, the gfxTextRuns are cached. I think that if we cache the itemized result, we can improve the performance. I don't want to back-out the font-name resolver. Because the patch is the base of my other works...

(In reply to comment #2) > Oshima-san and taken-san: > > Can you reproduce this slow rendering? No I can't reproduce. I don't think rendering of the URL is slower than other Japanese pages on yesterday's trunk build. I don't apply any patch.

Thanks. I'll attach a patch that should be used until bug 333659.

I have a similar problem only with my own build, not with distributed nightly build. My own build takes very long to load(or render) Japanese page. But nightly build at ftp.mozilla.org has no problem. What's my problem? I build on Gentoo and my .mozconfig is ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-optimize="-O2 -fomit-frame-pointer" #ac_add_options --without-system-nspr #ac_add_options --without-system-zlib #ac_add_options --without-system-jpeg #ac_add_options --without-system-png #ac_add_options --without-system-mng mk_add_options MOZ_CO_PROJECT=suite ac_add_options --enable-application=suite

If the nightly build is seamonkey, it may not be non-cairo build.

I create a draft for the patch. But I cannot test now. http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3409

Sorry, the previous patch is wrong. http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3410

Oops... http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3411

new patch: http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3412

maybe, buildable... http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3414

Is this a dupe of bug 357637?

(In reply to comment #18) > Is this a dupe of bug 357637? > Oh, you're right. I forget the bug, sorry. *** This bug has been marked as a duplicate of 357637 ***