Re: Interested in porting the font-rs rasterizer to FreeType

[Alexei Podtelezhnikov]

On Thu, Nov 12, 2020 at 9:50 AM Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:
> I've been tinkering with vector rasterization recently and I think
> I've learned enough to do the font-rs porting task from the GSoC ideas
> page. Just to be clear, I'll be doing this as my free-time
> contribution, not as a part of GSoC.

I appreciate your interest in this project. There is a lot to consider
before you jump in. Importantly, there are other projects with similar
claims of outstanding performance:
- https://github.com/raphlinus/font-rs
- https://github.com/servo/pathfinder
- https://github.com/mooman219/fontdue

So you have to consider the entire landscape. Why font-rs really?

> For the porting, I currently have these questions:
> * I plan to do a rewrite in C due to 1. dealing with build systems is
> annoying and Rust/Cargo integration with other build systems is
> immature, 2. the font-rs rasterizer code is rather simple (about <200
> lines), and 3. font-rs is not polished enough for production (for
> example lacking proper handling of out-of-bound coordinates). Just for
> a reference, someone at Google have ported the same code to Go:
> https://github.com/google/font-go. Does porting sound good in this
> case?

First, you need to study how the existing FT_Renderer's implemented in FreeType.
- https://www.freetype.org/freetype2/docs/reference/ft2-module_management.html
This is how it has to be impelmented. Therefore, there is no need to
port and integrate it into FreeType right away. You can create an
external wrapper FT_Renderer, which you can register and call from
FreeType. At least you should do it before porting as a proof of
concept.

> * Should the old rasterizer be retained? Probably yes, because the
> FT_RASTER_FLAG_DIRECT thing is coupled with a FT_Span structure that
> is not so much compatible with font-rs's idea (it uses a dense prefix
> sum structure rather than sparse spans). If we are going to keep the
> old renderer, then should we also provide a build-time option that
> allows defaulting to the old engine?

See, my previous comment about FT_Renderer modules. Leave smooth and
raster1 alone and work on a separate module, which does not have to
support FT_RASTER_FLAG_DIRECT. We are going to keep the original
rasterizers, until the new rasterizer can claim comparable
portability, extreme portability of pre-SIMD C89 kind.

Good luck,
Alexei