Bug 31931 – [Freetype] Don't use non-scalable fonts

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Duy Nguyen]

Hi,

I don't know if this is WebKit bug or cairo/freetype. About a month ago, every time I surfed pages with CJK letters inside, CPU went up 100% for a while, then back to normal. Recently this happens more often even with pages that have no CJK letters. I ran with gdb and stopped the program a few times while CPU spiked and got this call trace

#0  0xb5af410b in pcf_load_font () from /usr/lib/libfreetype.so.6
#1  0xb5af55c7 in PCF_Face_Init () from /usr/lib/libfreetype.so.6
#2  0xb5aad6b5 in open_face () from /usr/lib/libfreetype.so.6
#3  0xb5aaefb9 in FT_Open_Face () from /usr/lib/libfreetype.so.6
#4  0xb5ab0e66 in FT_New_Face () from /usr/lib/libfreetype.so.6
#5  0xb5ee858b in cairo_ft_scaled_font_lock_face () from /usr/lib/libcairo.so.2
#6  0xb7b23c72 in WebCore::SimpleFontData::containsCharacters () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#7  0xb7af8948 in WebCore::FontCache::getFontDataForCharacters () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#8  0xb78322cb in WebCore::Font::glyphDataForCharacter () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#9  0xb78411bb in WebCore::WidthIterator::advance () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#10 0xb7831a60 in WebCore::Font::floatWidthForSimpleText () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#11 0xb782a99d in WebCore::Font::floatWidth () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#12 0xb78ab2ec in WebCore::RenderBlock::findNextLineBreak () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#13 0xb78ad6b7 in WebCore::RenderBlock::layoutInlineChildren () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2
#14 0xb789fd56 in WebCore::RenderBlock::layoutBlock () from /home/pclouds/opt/webkit/lib/libwebkit-1.0.so.2

OProfile said most of time was spent inside zlib, which was probably because all my pcf fonts were compressed.

I tested with WebKit r51413, cairo 1.8.8, freetype 2.3.11. An easy test is open yahoo.co.jp. My PCF fonts are baemuk-fonts, font-adobe-75dpi, font-cursor-misc, font-misc-misc, unifont (Gentoo package names). Any suggestions how to find out where the bottleneck is?

[Duy Nguyen]

This is the list of fonts opened and number of open times (browsing yahoo.co.jp):

      1 open("/usr/share/fonts/corefonts/arialbd.ttf", O_RDONLY) = 19
     56 open("/usr/share/fonts/corefonts/arialbd.ttf", O_RDONLY) = 21
      1 open("/usr/share/fonts/corefonts/arialbd.ttf", O_RDONLY) = 26
      1 open("/usr/share/fonts/corefonts/arial.ttf", O_RDONLY) = 17
    355 open("/usr/share/fonts/corefonts/arial.ttf", O_RDONLY) = 21
     54 open("/usr/share/fonts/corefonts/courbd.ttf", O_RDONLY) = 21
    370 open("/usr/share/fonts/corefonts/couri.ttf", O_RDONLY) = 21
    329 open("/usr/share/fonts/corefonts/cour.ttf", O_RDONLY) = 21
    321 open("/usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf", O_RDONLY) = 21
    347 open("/usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf", O_RDONLY) = 21
    369 open("/usr/share/fonts/dejavu/DejaVuSans.ttf", O_RDONLY) = 21
    323 open("/usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf", O_RDONLY) = 21
    322 open("/usr/share/fonts/dejavu/DejaVuSerif.ttf", O_RDONLY) = 21
    356 open("/usr/share/fonts/freefont-ttf/FreeMono.ttf", O_RDONLY) = 21
    322 open("/usr/share/fonts/freefont-ttf/FreeSans.ttf", O_RDONLY) = 21
    390 open("/usr/share/fonts/freefont-ttf/FreeSerif.ttf", O_RDONLY) = 21
    389 open("/usr/share/fonts/misc/10x20.pcf.gz", O_RDONLY) = 21
    313 open("/usr/share/fonts/misc/12x13ja.pcf.gz", O_RDONLY) = 21
    358 open("/usr/share/fonts/misc/6x13.pcf.gz", O_RDONLY) = 21
    375 open("/usr/share/fonts/misc/9x15.pcf.gz", O_RDONLY) = 21
    328 open("/usr/share/fonts/misc/9x18.pcf.gz", O_RDONLY) = 21
    366 open("/usr/share/fonts/unifont/unifont-h.pcf.gz", O_RDONLY) = 21

[Holger Freyther]

Could you find out who decides to open the pcf fonts? Specially how it decides to use the AxB.pcf.gz fonts? In WebCore/platform/graphics/gtk/FontPlatformDataGtk.cpp we are driving FontConfig... you could use FcPatternPrint on the pattern we put into fontconfig and get out of it to see what we are selecting.

[Martin Robinson]

Can you post a link to the page that has this issue?

[Duy Nguyen]

(In reply to comment #3)
> Can you post a link to the page that has this issue?

http://www.yahoo.co.jp/ (not sure if it's still an issue as I'm not using webkit browser right now)

[Martin Robinson]

It seems that non-scalable fonts just give us issues. We should instruct WebKitGTK+ to never select a non-scalable font.

[Carlos Alberto Lopez Perez]

*** Bug 140290 has been marked as a duplicate of this bug. ***

[Carlos Alberto Lopez Perez]

I have uploaded a simple test case here where webkitgtk+ selects a non scalable font when ${etcfontconfig}/conf.d/70-no-bitmaps.conf is missing http://people.igalia.com/clopez/wkbug/140290/test.html

[Carlos Alberto Lopez Perez]

Created attachment 244472 [details]
Patch

[Martin Robinson]

Comment on attachment 244472 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244472&action=review

> Source/WebCore/platform/graphics/freetype/FontCacheFreeType.cpp:169
> +    // Always prefer scalable fonts. Otherwise we may end choosing fonts that look horrible.
> +    FcPatternAddBool(pattern.get(), FC_SCALABLE, FcTrue);

A better comment might be, "Never choose unscalable fonts, as they pixelate when displayed at different sizes." "look horrible" is a subjective statement. :)

[Carlos Alberto Lopez Perez]

Committed r178301: <http://trac.webkit.org/changeset/178301>