Each font load reloads the native font database (slow on OSX 10.6)

[sparecycles]

adam.freidin@gmail.com commented:

phantomjs --version
a customized 1.6.0 (development) with a functionally unmodified src/qt directory.

What steps will reproduce the problem?

1. use @font-face rules with phantomjs
2. observe slow loading times

Through the insertion of tracing statements in the webkit and qt sources, I found that each insertion of a new font causes a revalidation of the 400+ fonts installed on my system. A document with 20 fonts becomes painfully slow to load (over 15 seconds). Safari and chrome can consume the exact same request in ~500ms and ~800ms respectively.

Which operating system are you using?
OSX 10.6.8

Did you use binary PhantomJS or did you compile it from source?
source

I've identified the slow code as loadFromDatabase, and the problem is that the database is invalidated with each font insertion. Getting QRawFont working might be the solution here, or switching away from native font rendering for loaded fonts.

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #488.
🌟   4 people had starred this issue at the time of migration.

[sparecycles]

adam.freidin@gmail.com commented:

Nevermind... it looks like the WebKit guys are way ahead of me.

https://bugs.webkit.org/show_bug.cgi?id=51106

Looking forward to phantomjs 1.7 with the latest WebKit and Qt 4.8.1 sources integrated =)

[sparecycles]

adam.freidin@gmail.com commented:

Update: looking forward to phantomjs 1.7 with the latest QtWebKit and Qt 5 sources integrated.

see http://trac.webkit.org/changeset/113968

[graffic]

Problem still alive here. fontd in Mac takes 100% cpu when enough phantomjs processes run.

[morganick]

I'm also witnessing this. PhantomJS 1.9.7

[morganick]

A bit more information: We use Typekit for our fonts in our app. If I don't load the Typekit fonts, the test suite runs 7X faster. All of the Typekit fonts are cached using VCR so it isn't network.

When I load the fonts, fontd just starts consuming the CPU.

[sparecycles]

Glad to see this is getting attention 2 years later.

My original concern was not that font loading was slow but that the fonts were being loaded into the database and then the database/font mapping was being refreshed, at all. I believe this broke a font I was trying to load which wasn't properly identified (as in whatever the font database is keyed with, this font lacked the metadata). I had no way to confirm this diagnosis, but I found this font worked in other browsers (including webkit-based browsers_ but not phantomjs.

TL;DR; This was always secondary concern intended to provide a motivation to bypass the database for font loading, as I believe that bypassing the database would improve both correctness and speed.

[kayline]

I'm also having this problem with PhantomJS 1.9.7 and Typekit. Without Typekit our specs run in about 5 minutes, with Typekit they take 23 minutes. fontd just goes nuts and consumes 99% of the CPU.

We tried capybara-webkit and had a similar problem. It doesn't happen using selenium with Firefox, but obviously we'd rather run headless.

[jamesshore]

👍

I'm also seeing this issue on PhantomJS 1.9.7 when loading a page that uses Typekit. Mac OS 10.8.5.

Edit Just upgraded to 1.9.8, problem still occurs. The time cost of using Typekit to load three fonts is about 8 seconds for a single page load.

[jamesshore]

Just confirmed that this issue still exists on PhantomJS 1.9.8 on Mac OS "Yosemite" 10.10.1.

[bcarpenter]

Seeing this issue as well. PhantomJS 1.9.7.0 on OSX 10.9.5.

[dustinblackman]

Confirmed still an issue on OSX 10.11

[bcarpenter]

Not really a fix, but a workaround I use is as follows (i.e. don't load Typekit during automated tests):

    - unless Rails.env.test? # Typekit slows down phantomjs https://github.com/ariya/phantomjs/issues/10488
      = javascript_include_tag "//use.typekit.net/ppd2bsh.js"
      :javascript
        try{Typekit.load();}catch(e){}

[vitallium]

Could someone try again with 2.5 binary? Thanks!

[stale]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!