On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod <beh...@behdad.org> wrote:
> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov <apodt...@gmail.com> > wrote: > >> > >> > Wanted to point out that compiling with gcc and adding >> "-stack-usage=2000" to get reports about stacks larger than 2000 bytes is >> probably the easiest way to track down large stacks at the moment. Note >> that af_cjk_metrics_init_widths (44480 bytes) and >> af_latin_metrics_init_widths (52992 bytes) are by far the largest. >> cf2_interpT2CharString (27520 bytes) is also surprisingly large. There are >> a few others like the rasterizer stacks that are between 10-20kb which one >> may also want to look into, but these have been less problematic on my >> experience (though that may have been due to the even larger stacks being >> allocated first). Just wanted to point out how to measure and that the >> rasterizer might not be the first place to look. >> >> That is surprisingly large. Someone should examine how much of it is >> actually used. The rendering pool of "visited cells" (pixels) is >> rather predictable for a given outline. That is why it is easy for me. >> > > I took a look at the autohinter one. The problem comes from: > > AF_LatinBlueRec blues[AF_BLUE_STRINGSET_MAX]; > > in struct AF_LatinAxisRec_. The value of AF_BLUE_STRINGSET_MAX is ~260. > > My gut feeling is that that's a typo and should be: > > AF_LatinBlueRec blues[AF_BLUE_STRINGSET_MAX_LEN]; > > where AF_BLUE_STRINGSET_MAX_LEN is 8. I haven't tested that. > Same thing in afcjk.h. I'm finding these using: $ make CPPFLAGS=-Wframe-larger-than=4096
