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 < anurag105cse...@bpitindia.edu.in> 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:* freetype-devel@nongnu.org <freetype-devel@nongnu.org> > *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 >