freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

font-rs port performance and GSoC status update


From: Anurag Thakur
Subject: font-rs port performance and GSoC status update
Date: Sat, 1 Jul 2023 11:06:09 +0000

Hi all,

 

I have been working on analyzing the performance of my font-rs port for freetype (`dense` module) and want to discuss the results.

 

I decided to compare it with fontdue since it was created as a fork of font-rs and claims to be even faster.

 

I ran the benchmarks included in the fontdue git repo, that compare fontdue and freetype (using freetype-rs crate), and

it seems clear that for sizes under 200ppem fontdue appears to be 2-3x faster. However, this changes once the font size crosses

500, after that freetype outpaces fontdue and the difference between a quadratic and linear time algorithm becomes apparent.

 

So, even in the best-case scenario, the improvements proposed in font-rs are only valid till ~500ppem size.

 

This was on x86_64 where fontdue has a SIMD implementation. On arm64 where fontdue doesn’t seem to support SIMD (ARM NEON)

it scores even worse, becoming slower than freetype after roughly 300ppem.

 

I don’t know how common font sizes greater than 500 are in real-world use cases, but it is something to keep in mind.

 

You can reproduce the benchmark results like so:

 

1. Clone the fontdue repo from Github

2. Enter the `dev` directory and run `cargo bench --features freetype_benchmark`

3. By default it also benchmarks other libraries, you can control it by modifying the `dev/benches/rasterize.rs` file

 

 

Now taking a look at the `dense` module, using the `ftbench` utility the overall quadratic trend is present here as well, however the current

implementation seems to be just barely faster than freetype with SIMD and on arm64 without SIMD, its just plain worse.

 

Currently I am running more benchmarks and trying to isolate the reason why the `dense` module isn’t as fast as fontdue, whether it is because

Of other differences between fontdue and freetype or missing optimizations in the module. If I find any optimizations that can be

ported over, I will work on that.

 

The results for all the benchmarks are attached.

 

As for my GSoC phase 1 progress, I have added support for cmake and meson to the module and am working on improving the documentation including:

-         Migrating Readme and INSTALL files to markdown

-         Add documentation on adding a new module to FreeType

-         Compiling and testing FreeType on an Android device

-         Setting up a development environment, debugging and testing FreeType

-         Detailed description of the freetype `smooth` raster algorithm

 

The work can be seen on `gsoc-anurag-2023` and `gsoc-anurag-docs-2023` branches

 

I will post another update once I understand the performance characteristics more clearly.

Regards

Anurag

Attachment: fontdue_arm64_1k.png
Description: fontdue_arm64_1k.png

Attachment: fontdue_arm64_10k.png
Description: fontdue_arm64_10k.png

Attachment: fontdue_arm64_200.png
Description: fontdue_arm64_200.png

Attachment: fontdue_x86-64_1k.png
Description: fontdue_x86-64_1k.png

Attachment: fontdue_x86-64_10k.png
Description: fontdue_x86-64_10k.png

Attachment: fontdue_x86-64_200.png
Description: fontdue_x86-64_200.png

Attachment: ftbench_arm64_1k.png
Description: ftbench_arm64_1k.png

Attachment: ftbench_arm64_10k.png
Description: ftbench_arm64_10k.png

Attachment: ftbench_arm64_200.png
Description: ftbench_arm64_200.png

Attachment: ftbench_x86-64_1k.png
Description: ftbench_x86-64_1k.png

Attachment: ftbench_x86-64_10k.png
Description: ftbench_x86-64_10k.png

Attachment: ftbench_x86-64_200.png
Description: ftbench_x86-64_200.png


reply via email to

[Prev in Thread] Current Thread [Next in Thread]