dear: I get webkit-r62241 source form Archived Nightly Builds of Trunk, build GTK Port, then open (http://www.sina.com.cn、http://www.sohu.com.cn)(Simplified Chinese) very slow. Then i get latest Nightly Builds,also very slow.I guess because of font process,add i open (http://www.bbc.com) is normal. please tell me how to do this, tks!
Seems that libz and libfreetype show on top of the profile when loading that page. Could be a font rendering issue.
After an initial glance at this, it looks like this is due to the implementation of FontCache::getFontDataForCharacters for the FreeType backend. It seems be checking if all FontConfig fallbacks contain the characters needed. This requires locking and unlocking each FreeType face for these fallback fonts. Really, we should probably be asking FontConfig directly if it has a good font for these characters. Likely, once we fix this issue there will be other performance issues with CJK characters we need to tackle as well.
Created attachment 68426 [details] Profile graph from Alex
Created attachment 68472 [details] Patch for this issue
Attachment 68472 [details] did not build on gtk: Build output: http://queues.webkit.org/results/4061091
This fix doesn't build because the patch depends on 36548.
Comment on attachment 68472 [details] Patch for this issue View in context: https://bugs.webkit.org/attachment.cgi?id=68472&action=review Makes sense to me. > WebCore/platform/graphics/cairo/FontCacheFreeType.cpp:-50 > - > - // FIXME: This should not happen, apparently. We are null-checking > - // for now just to avoid crashing. I'd keep this FIXME comment for now, till it's accurate to remove it, as discussed on IRC.
this problem is because of font-config, i modify font-config, and leave only one font characters, browser show page normal. (In reply to comment #1) > Seems that libz and libfreetype show on top of the profile when loading that page. Could be a font rendering issue.
(In reply to comment #8) > this problem is because of font-config, i modify font-config, and leave only one font characters, browser show page normal. Can you confirm that when you have your original FontConfig setup (the slow one) that you saw the same issue in FireFox and/or Chromium.
yes,I can confirm that I use the same fontconfig , firefox is normal, but webkit open page very slow. My linux system have not install chromium. (In reply to comment #9) > (In reply to comment #8) > > this problem is because of font-config, i modify font-config, and leave only one font characters, browser show page normal. > > Can you confirm that when you have your original FontConfig setup (the slow one) that you saw the same issue in FireFox and/or Chromium.
Okay. There's definitely a bug here, so we should keep this open until a fix lands.
Comment on attachment 68472 [details] Patch for this issue Clearing the review flag, because I have another version of this patch which fixes some issues as well as fixing this method for custom fonts.
Incorrect fallback determination also seems to expose issues with this test: editing/selection/extend-selection.html
Created attachment 68992 [details] Patch for this issue also fixing custom fonts
Created attachment 71555 [details] Profile of loading the page with the patch applied Apparently the patch fixes the problem, you can check the new profile of loading the same page.
Comment on attachment 68992 [details] Patch for this issue also fixing custom fonts Looks right to me, but where did you get the mostly empty font? It's important to clearly identify that, and be sure the licensing is OK
(In reply to comment #16) > (From update of attachment 68992 [details]) > Looks right to me, but where did you get the mostly empty font? It's important to clearly identify that, and be sure the licensing is OK Good point. :) I created the font myself in fontforge by selecting "New" and drawing a polyhedron for capital A. All other glyphs are empty and use whatever defaults fontforge selected. I'll make a note of that in the ChangeLog.
Committed r70688: <http://trac.webkit.org/changeset/70688>
http://trac.webkit.org/changeset/70688 might have broken GTK Linux 64-bit Debug