On Thu, Nov 12, 2020 at 9:50 AM Tatsuyuki Ishi <ishitatsuy...@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
