Re: Progress update on alternative rendering engines project

I don't think this (caching flatten outlines) is a good idea. Pretty much
all serious implementations cache the rendered image. And pretty much all
uses of FreeType don't render the entire glyph set. And must
implementations care a lot more about loading performance. I know you are
suggesting new API. I just don't see how this is useful, unless I'm
misunderstanding it.

behdad
http://behdad.org/


On Sun, Oct 8, 2023 at 12:59 PM Anurag Thakur <
[email protected]> wrote:

> 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
>
>
> ------------------------------
> *From:* Anurag Thakur
> *Sent:* Wednesday, October 4, 2023 2:57 AM
> *To:* [email protected] <[email protected]>
> *Subject:* Progress update on alternative rendering engines project
>
> 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.
>
> Regards,
> Anurag
>