> I don't think this (caching flatten outlines) is a good idea.
Honestly, I don't have an opinion on this.
> 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
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
Hi Anurag,
Would you like to try smooth_malloc branch for fun? I will announce it soon.
Alexei
> On Oct 3, 2023, at 17:33, Anurag Thakur
> wrote:
>
>
> Hi all,
>
> Here's a quick update on the project status:
>
> I have implemented the "preloading" optimization where FreeType can perform
rk reports.
Regards
Anurag
From: Anurag Thakur
Sent: Saturday, August 5, 2023 5:46:53 PM
To: Anurag Thakur ; Werner LEMBERG
Cc: freetype-devel@nongnu.org ;
raph.lev...@gmail.com
Subject: RE: Progress update on alternative rendering engines project
I tested
___
From: Werner LEMBERG
Sent: Saturday, August 5, 2023 9:57:06 am
To: Anurag Thakur
Cc: freetype-devel@nongnu.org ;
raph.lev...@gmail.com
Subject: Re: Progress update on alternative rendering engines project
Hello Anurag,
> From what I understood, the main
Hello Anurag,
> From what I understood, the main performance improvement that
> fontdue claims to have is that it stores the font outlines
> differently, i.e. it seems to perform the curve flattening at
> initial load and stores the outline in the form of "v_lines" and
> "m_lines", presumably
> I am currently working on implementing optimizations from fontdue in
> the `dense` module.
Any progress code-wise? Two weeks have passed, and I only see minor
adjustments to the MarkDown document conversions – and no report from
you :-)
Werner
