Skip to content

Conversation

@madig
Copy link

@madig madig commented Jun 7, 2022

No description provided.

@madig madig mentioned this pull request Jun 7, 2022
@chrissimpkins
Copy link
Member

chrissimpkins commented Jun 7, 2022

Thanks Nikolaus! I am working on a draft locally. I will merge this into my branch and add my edits on top.

@chrissimpkins chrissimpkins marked this pull request as ready for review June 7, 2022 21:08
@chrissimpkins chrissimpkins merged commit 861466c into googlefonts:what-why-when Jun 7, 2022
@chrissimpkins
Copy link
Member

Pushed what I currently have to the remote. More to come. Thanks again Nikolaus!


### Current Tools

fontmake. It's the glue that binds together ufo2ft, fontTools and some other codebases to take any of the usual font formats (UFOs, Designspace + UFOs and Glyphs.app files) and produce font binaries (TTF, CFF(2); static, interpolated static, variable).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nanoemoji, though limited in scope, may bear mention. Significant primarily because it uses python to write ninja and that has proven to be very effective for those parts of the process that are readily amenable to ninja.

A section on low hanging fruit, such as introducing parallelism to fontmake, would be interesting.

An interesting decision is coming: should we try to speed up fontmake before, or instead of, waiting on a new compiler.


### Key Limitations

* Python is bad at embarrasingly parallel tasks like instance generation and glyph compilation due to overhead and lacking multicore facilities.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

even if we imagine a ninja'fied fontmake?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd typically ninja complete build steps, generating glyf and gvar is probably impractical due to granularity and overhead. Instance generation, maybe, depending on the project. I think googlefonts/gftools#569 implements something.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instance generation works fine, which is (partly) what I'm doing with gftools.builder.ninja. A gftools-builder run (which is intended to bring an entire family to production) is a much larger superset of operations than a fontmake run:

  • It typically runs on more than one source file at once (i.e. Upright and Italic sources for a family)
  • It typically builds a wide variety of output fonts (variable TTF, TTF, OTF)
  • There are typically other steps that you want to orchestrate in a make-like context (autohinting each TTF output, converting each TTF to a webfont, running hotfix scripts, converting each TTF output to building STAT tables when all output variable TTFs are complete)

So that gains a lot from using ninja. I get roughly a 3x speedup.

It is possible to break up some of the operations that fontmake does and use ninja to orchestrate them, in some contexts. Generally this is when you are dealing with static instances (-i flag):

  • Creating instance UFOs from a Designspace file is currently done in serial, can be done in parallel.
  • Creating instance binaries from each instance UFO is current done in serial, can be done in parallel.
  • Creating master binaries from each master UFO is current done in serial, can be done in parallel.

On the other hand, building a single variable font would only involve the last of these operations, and I'm not convinced that's enough of a gain to warrant the work of adding ninja orchestration.

Just so you see the degree of separable operations in a gftools-builder run, here is a ninja -t graph dump of gftools.builder.ninja for a typical font family:

ninja

* It's easy to run into performance problems with OpenType Layout table repacking, which quickly consumes a large part of the compile time.
* Codebases have grown organically by adding new things on top, some parts are byzantine and hard to change, making optimizations or rearranging code paths hard.
* VF generation requires compiling all masters fully and then merging them, instead of generating variable data directly.
* fontmake is underloved from a maintenance perspective, with some low hanging performance fruits continuing to hang.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is true. The last time we had this discussion (fonttools/fonttools#1095) we concluded there weren't many low-hanging fruit.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, maybe I should have written instead "it still keeps writing out intermediate UFOs even when not requested" which holds up the process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants