Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sparecycles opened this issue Apr 9, 2012 · 14 comments
Closed

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

sparecycles opened this issue Apr 9, 2012 · 14 comments

Comments

@sparecycles
Copy link

@sparecycles sparecycles commented Apr 9, 2012

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
Copy link
Author

@sparecycles sparecycles commented Apr 10, 2012

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
Copy link
Author

@sparecycles sparecycles commented Apr 15, 2012

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
Copy link

@graffic graffic commented Dec 3, 2013

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

@morganick
Copy link

@morganick morganick commented Sep 5, 2014

I'm also witnessing this. PhantomJS 1.9.7

@morganick
Copy link

@morganick morganick commented Sep 16, 2014

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
Copy link
Author

@sparecycles sparecycles commented Sep 22, 2014

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
Copy link

@kayline kayline commented Oct 24, 2014

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
Copy link

@jamesshore jamesshore commented Dec 22, 2014

👍

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
Copy link

@jamesshore jamesshore commented Jan 7, 2015

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

@bcarpenter
Copy link

@bcarpenter bcarpenter commented Feb 18, 2015

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

@dustinblackman
Copy link

@dustinblackman dustinblackman commented Jan 16, 2016

Confirmed still an issue on OSX 10.11

@bcarpenter
Copy link

@bcarpenter bcarpenter commented Jan 16, 2016

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
Copy link
Collaborator

@vitallium vitallium commented Jan 11, 2017

Could someone try again with 2.5 binary? Thanks!

@vitallium vitallium self-assigned this Jan 11, 2017
@vitallium vitallium added this to the Release 2.5 milestone Jan 11, 2017
@ghost ghost removed this from the Release 2.5 milestone Jan 10, 2018
@stale stale bot added the stale label Dec 25, 2019
@stale
Copy link

@stale stale bot commented Dec 28, 2019

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!

@stale stale bot closed this Dec 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.