Here's a detailed explanation for my implementation:
The "preloading" optimization has a simple concept: Load the glyph data and perform curve flattening at load time, to reduce render time.
In FreeType terminology, we are moving FT_Load_Glyph and FT_Decompose_Outline calls to
FT_New_Face, so that they only have to be performed
once per glyph and every subsequent invocation can directly call FT_Render_Glyph.
So for every call to FT_Render_Glyph we don't have to perform the "cubic_to" and "conic_to" calculations.
It's a tradeoff between memory usage and rendering speed.
This is essentially what my implementation does, I have created a function
FT_New_Face2 which checks for the
PRELOAD flag.
Once the face creation succeeds, if the flag is present it iterates through all the glyphs in the face and calls
FT_Load_Glyph on them.
An array of GlyphSlots (glyph_array) is created under the face struct to store this data.
After this, curve flattening is performed and the resulting lines are stored.
To store the line data I added FT_PreLine to FT_GlyphSlot that represents a linkedlist of
from and to points for each line.
The user simply has to call FT_Render_Glyph to get the output, which simply iterates over the "prelines" linkedlist and calls "line_to"
To get the data they have to access the GlyphSlot by face->glyph_data[glyph_index]
The current implementation does not support changing the font size, it has to be specified during the New_Face call
fontdue implements this by choosing a fixed size to perform curve flattening at and then scaling the lines for user
provided sizes, however this leads to jagged edges at very high resolutions.
To benchmark the rendering I have replaced the FT_Load_Glyph calls with FT_Refresh_Glyph function whose only job is to clear the bitmap
data and set the correct format for the GlyphSlot since FT_Rendering an already rendered glyph did not work.
This approach also does not support font hinting (as is the case with fontdue) and I am unsure if/how it could be supported.
I have tried to be minimally invasive with this change, however in my opinion the design is too different from the current FreeType API and is probably not worth the
extra effort for the ~5% gain it provides in performance.
I have also implemented SIMD optimizations from fontdue and added support for ARM NEON, benchmarks attached.
As for the line drawing optimizations, the algorithm is actually pretty similar. I was unable to get any improvements from it in my testing, so did not implement it.
> I
was actually hoping that you would find some
> interesting
ideas in Pathfinder, etc in the line drawing algorithms.
I haven't looked at pathfinder yet because it seemed more GPU focused. I did try searching for other algorithms but couldn't find any.
All the searches lead to some variant of the same algorithm.
I do have 1 optimization in mind though, since the drawing buffer in the dense module is an array, it should be suitable for multithreading. The lines could be drawn all at once instead of
sequentially. Is multithreading acceptable for FreeType?
Now that I have explored most optimizations I could find, I am working on cleaning up the git history and my final report.
Regards
Anurag
Hi all,
Here's a quick update on the project status:
I have implemented the "preloading" optimization where FreeType can perform curve flattening at load time to reduce render
time later.
Although the difference in performance seems to be very little (since the accumulation part takes the majority of rendering time)
(benchmarks attached).
I am almost done with the rendering algorithm improvement from fontdue as well. Benchmarks coming soon.
Will send a more detailed report explaining my implementation in detail later today and then will work towards the final submission.