8 ms·

Neat. I can't help but wonder if this will fall victim to the "last 10% is the hardest" rule? Will going from tech demo to production ready remove the performan

Neat. I can't help but wonder if this will fall victim to the "last 10% is the hardest" rule? Will going from tech demo to production ready remove the performance gain? It sounds like you're claiming that FreeType is slower because the parsing/accumulation implementations are slower. It's far from my area of expertise, but wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths? Edit: Author is a heavyweight in font rendering circles. Excuse my ignorance. Just wary of "10x faster with 90% of functionality!" benchmarks.

zellyn 10y ago
Raph really, really knows his stuff. His interview on the New Rustacean podcast starts with a summary of his background: Gimp, Ghostview, android font rendering.
- catawbasam 10y ago
  Yup, I still remember being blown away by his dissertation. That he is using Rust in earnest is enough reason for me to take another look at the language.
- microcolonel 10y ago
  For what it's worth; Gimp, Ghostscript, and Android all use FreeType for text rendering. At best, they would require him to know how to use FreeType bitmaps correctly (i.e. gamma-correct blending, when to multiply colours in). Though he could easily go beyond that, it is very interesting stuff and I find it incredibly hard to stop myself from reading into FreeType.
- cdbattags 10y ago
  Any chance we can get a link? Edit: Whoops, see below. And for the lazy: http://www.newrustacean.com/show_notes/interview/_2/index.html http://www.newrustacean.com/show_notes/interview/_2/index.ht... (credit to @wscott)
- zellyn 10y ago
  Your 10x speed, 90% functionality caution is definitely warranted. I've lost count of how many times I've seen "we run Python/Ruby/Perl/whatever" 3x faster, just haven't implemented exceptions and monkey-patching yet. :-)
- on_and_off 10y ago
  As a font neophyte I can only say that he sounds like he breathes fonts. His interview in Android dev Backstage was very interesting : http://androidbackstage.blogspot.fr/2015/01/episode-20-fonts-and-audio.html http://androidbackstage.blogspot.fr/2015/01/episode-20-fonts... (And the whole podcast is an easy recommandation. Googlers talking about Android dev stuff from an insider perspective)
oldmanjay 10y ago
Being open source is no guarantee of being fast, or good, or anything. The only thing you really know you're getting is the ability to inspect the code to figure out if it suits your needs instead of having to assume.
jerf 10y ago
"It sounds like you're claiming that FreeType is slower because the parsing/accumulation implementations are slower." This is one of those performance drains across many languages that we often don't see because our weak languages don't let us. Manifesting an array for a consumer that only wants to iterate on it once, in order, with no backtracking, is a common antipattern. Just as I'd look askance at any putative "next big language" that doesn't have any sort of closure support, I look askance at "next big languages" that don't have iterators.
- deleted 10y ago
  [deleted]
pcwalton 10y ago
> wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths You'd be surprised how often SIMD goes unused. libpng, for example, doesn't use it on x86… Outside of games, scientific computing, and a few other fields, it's notable how little of the hardware in our devices actually gets put to use.
- zzleeper 10y ago
  I wonder whose fault is that.. if you build a feature that almost on one will use, then is the 'API' too arcane, everyone too lazy, or are there no tools available to ease the pain?
  - 14113 10y ago
    No tools available, or at least, none that are easy to use. It's the classic parallelism problem: tools are either too low level (e.g. CUDA/OpenCL for the GPU space) for day to day developers to leverage effectively, or too high level to provide the performance in the other 10% of the codebase, wiping out your parallelism benefits. In this space, the low level alternative is manually writing SIMD x86 instructions, or using a similarly low level C library to do the same. The alternative is switching to something like haskell and using one of their high level array manipulation DSLs. In the first case, you have to explicitly manage the parallelism, and there _will_ be bugs there, in the second case you probably lose more performance in the other 90% of your application by switching to (say) haskell than you gain in parallelism. In terms of automation, SIMD is hard to automatically implement (i.e. through the compiler) with a lot of traditional programming languages (e.g. C), and hard to add to dynamic languages, as you end up adding extra code paths/jit passes for each new type of simd/parallelism hardware construct available.
  - moosingin3space 10y ago
    I believe that C is in part to blame, because the ANSI C abstract machine describes a single-threaded processor.
    - vardump 10y ago
nilved 10y ago
> It's far from my area of expertise, but wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths? No, 20 y/o software had Heartbleed. Just because software is old doesn't mean it's battle-tested.
- moosingin3space 10y ago
  And just because software is mature, open-source, actively developed does not imply it is optimal for today's hardware. See WebRender versus GDI/GTK2, for instance.
elcapitan 10y ago
Author: > The current state of the code is quite rough. The code isn't well organized, and it's basically not ready for prime time. From what I can see in https://github.com/google/font-rs/blob/master/src/font.rs https://github.com/google/font-rs/blob/master/src/font.rs, this is what is missing: * support of CFF-based fonts (that is "postscript-flavored outlines" (i.e. cubic) OTF files) * "Advanced Typographic Tables" (see Opentype spec: https://www.microsoft.com/typography/otspec/otff.htm https://www.microsoft.com/typography/otspec/otff.htm), this is what is needed to render more complex non-latin languages like Arabic etc, because it defines context-specific replacements and positioning, but also opentype-level kerning * support for the kerning table * support for slightly more exotic TTF variations like EOT and WOFF for webfonts * hinting support for smaller rendering sizes Most of these things are supported by Freetype, and are probably a considerable amount of work to add. Once you add them into the rendering calculations, the abstractions in the code would have to be refactored and the code would become more complex and probably slower. Having said that, it's still a nice implementation and easy to read, something I wouldn't necessarily say about Freetype ;)
- pcwalton 10y ago
  > Once you add them into the rendering calculations, the abstractions in the code would have to be refactored and the code would become more complex and probably slower. These features don't have much to do with the core rasterization algorithm, which is where the vast majority of the time is typically spent. So I wouldn't expect things to go slower.
  - elcapitan 10y ago
    The hinting is definitely rasterization related, isn't it?
    - pcwalton 10y ago
      Well, sure, but it's increasingly common to just not do hinting these days. For example, Mac, iOS, and Android (from what I can gather) don't. In any case, hinting just changes point positions. It doesn't affect the way the rasterizer works at a fundamental level, I don't believe.
brohee 10y ago
> wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths? The tradeoffs that made the most sense 20 years ago are not those that would lead to the fastest implementation on current hardware. This is not so much the Freetype is unoptimized, it's that old, possibly wrong optimizations are pretty much baked in now... Modern CPU have massively more cache and have vectorization instructions, which make the optimal solution very different from the one optimal for the Pentium II that was top of the line when Freetype was first conceived... It's also acceptable to use vastly more memory, Freetype dates from a time where a beefy desktop machine had maybe 32Mb of RAM...

zellyn 10y ago

Raph really, really knows his stuff. His interview on the New Rustacean podcast starts with a summary of his background: Gimp, Ghostview, android font rendering.

catawbasam 10y ago
Yup, I still remember being blown away by his dissertation. That he is using Rust in earnest is enough reason for me to take another look at the language.
microcolonel 10y ago
For what it's worth; Gimp, Ghostscript, and Android all use FreeType for text rendering. At best, they would require him to know how to use FreeType bitmaps correctly (i.e. gamma-correct blending, when to multiply colours in). Though he could easily go beyond that, it is very interesting stuff and I find it incredibly hard to stop myself from reading into FreeType.
cdbattags 10y ago
Any chance we can get a link? Edit: Whoops, see below. And for the lazy: http://www.newrustacean.com/show_notes/interview/_2/index.html http://www.newrustacean.com/show_notes/interview/_2/index.ht... (credit to @wscott)
zellyn 10y ago
Your 10x speed, 90% functionality caution is definitely warranted. I've lost count of how many times I've seen "we run Python/Ruby/Perl/whatever" 3x faster, just haven't implemented exceptions and monkey-patching yet. :-)
on_and_off 10y ago
As a font neophyte I can only say that he sounds like he breathes fonts. His interview in Android dev Backstage was very interesting : http://androidbackstage.blogspot.fr/2015/01/episode-20-fonts-and-audio.html http://androidbackstage.blogspot.fr/2015/01/episode-20-fonts... (And the whole podcast is an easy recommandation. Googlers talking about Android dev stuff from an insider perspective)

oldmanjay 10y ago

Being open source is no guarantee of being fast, or good, or anything. The only thing you really know you're getting is the ability to inspect the code to figure out if it suits your needs instead of having to assume.

jerf 10y ago

"It sounds like you're claiming that FreeType is slower because the parsing/accumulation implementations are slower." This is one of those performance drains across many languages that we often don't see because our weak languages don't let us. Manifesting an array for a consumer that only wants to iterate on it once, in order, with no backtracking, is a common antipattern. Just as I'd look askance at any putative "next big language" that doesn't have any sort of closure support, I look askance at "next big languages" that don't have iterators.

deleted 10y ago
[deleted]

pcwalton 10y ago

> wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths You'd be surprised how often SIMD goes unused. libpng, for example, doesn't use it on x86… Outside of games, scientific computing, and a few other fields, it's notable how little of the hardware in our devices actually gets put to use.

zzleeper 10y ago
I wonder whose fault is that.. if you build a feature that almost on one will use, then is the 'API' too arcane, everyone too lazy, or are there no tools available to ease the pain?
- 14113 10y ago
  No tools available, or at least, none that are easy to use. It's the classic parallelism problem: tools are either too low level (e.g. CUDA/OpenCL for the GPU space) for day to day developers to leverage effectively, or too high level to provide the performance in the other 10% of the codebase, wiping out your parallelism benefits. In this space, the low level alternative is manually writing SIMD x86 instructions, or using a similarly low level C library to do the same. The alternative is switching to something like haskell and using one of their high level array manipulation DSLs. In the first case, you have to explicitly manage the parallelism, and there _will_ be bugs there, in the second case you probably lose more performance in the other 90% of your application by switching to (say) haskell than you gain in parallelism. In terms of automation, SIMD is hard to automatically implement (i.e. through the compiler) with a lot of traditional programming languages (e.g. C), and hard to add to dynamic languages, as you end up adding extra code paths/jit passes for each new type of simd/parallelism hardware construct available.
- moosingin3space 10y ago
  I believe that C is in part to blame, because the ANSI C abstract machine describes a single-threaded processor.
  - vardump 10y ago

nilved 10y ago

> It's far from my area of expertise, but wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths? No, 20 y/o software had Heartbleed. Just because software is old doesn't mean it's battle-tested.

moosingin3space 10y ago
And just because software is mature, open-source, actively developed does not imply it is optimal for today's hardware. See WebRender versus GDI/GTK2, for instance.

elcapitan 10y ago

Author: > The current state of the code is quite rough. The code isn't well organized, and it's basically not ready for prime time. From what I can see in https://github.com/google/font-rs/blob/master/src/font.rs https://github.com/google/font-rs/blob/master/src/font.rs, this is what is missing: * support of CFF-based fonts (that is "postscript-flavored outlines" (i.e. cubic) OTF files) * "Advanced Typographic Tables" (see Opentype spec: https://www.microsoft.com/typography/otspec/otff.htm https://www.microsoft.com/typography/otspec/otff.htm), this is what is needed to render more complex non-latin languages like Arabic etc, because it defines context-specific replacements and positioning, but also opentype-level kerning * support for the kerning table * support for slightly more exotic TTF variations like EOT and WOFF for webfonts * hinting support for smaller rendering sizes Most of these things are supported by Freetype, and are probably a considerable amount of work to add. Once you add them into the rendering calculations, the abstractions in the code would have to be refactored and the code would become more complex and probably slower. Having said that, it's still a nice implementation and easy to read, something I wouldn't necessarily say about Freetype ;)

pcwalton 10y ago
> Once you add them into the rendering calculations, the abstractions in the code would have to be refactored and the code would become more complex and probably slower. These features don't have much to do with the core rasterization algorithm, which is where the vast majority of the time is typically spent. So I wouldn't expect things to go slower.
- elcapitan 10y ago
  The hinting is definitely rasterization related, isn't it?
  - pcwalton 10y ago
    Well, sure, but it's increasingly common to just not do hinting these days. For example, Mac, iOS, and Android (from what I can gather) don't. In any case, hinting just changes point positions. It doesn't affect the way the rasterizer works at a fundamental level, I don't believe.

brohee 10y ago

> wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths? The tradeoffs that made the most sense 20 years ago are not those that would lead to the fastest implementation on current hardware. This is not so much the Freetype is unoptimized, it's that old, possibly wrong optimizations are pretty much baked in now... Modern CPU have massively more cache and have vectorization instructions, which make the optimal solution very different from the one optimal for the Pentium II that was top of the line when Freetype was first conceived... It's also acceptable to use vastly more memory, Freetype dates from a time where a beefy desktop machine had maybe 32Mb of RAM...