Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
Latest commit ad0b79e Jul 12, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
benches Use a different glyph for benchmarking Jun 13, 2018
examples Add rustfmt.toml May 18, 2018
fonts Added regression tests for glyph lookup. (#35) Oct 17, 2018
.gitignore Make it work with stable Rust Mar 5, 2016
.travis.yml Add TravisCI Jan 29, 2018 Initial commit of font renderer Jun 19, 2015
Cargo.toml Issue #9 : Switched to native SIMD instructions in Rust. Deleted buil… Sep 2, 2018
LICENSE Update Aug 2, 2016
rustfmt.toml Add rustfmt.toml May 18, 2018


This is a font renderer written (mostly) in pure, safe Rust. There is an optional SIMD module for cumulative sum, currently written in C SSE3 intrinsics.

The current state of the code is quite rough. The code isn't well organized, and it's basically not ready for prime time. However, it runs well enough to run benchmarks, and those benchmarks suggest extremely promising performance compared with Freetype and freetype-go (the loose port of Freetype to Go).

The rasterizer is basically very similar in design to libart, except that vectors are drawn immediately into the buffer, rather than sorted and stored in intermediate form, and that the buffer for rasterization is a dense array rather than a sparse data structure. The main motivation for the latter is to avoid branch misprediction and to better exploit data parallelism, both valid trends in optimization since libart was originally written.

It's worth comparing the algorithm with that in Anti-Grain Geometry. The original libart algorithm was also inspiration for the current antialiased renderer in Freetype. All these renderers share many common features, particularly computation of exact subpixel areas and an integration step to determine winding number (and convert to pixel value), but differ in details such as data structures to represent the vectors and the buffer.

The parsing of TrueType glyph data is done in pull-parser style, as iterators over the lower-level data. This technique basically avoids allocating any memory for representation of points and quadratic Beziers.


The main author is Raph Levien.


We gladly accept contributions via GitHub pull requests, as long as the author has signed the Google Contributor License. Please see for more details.


This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

You can’t perform that action at this time.