What I said is wrong. But the blues array should be dynamically allocated, and use a embedded version for small values. I'll work on it.
behdad http://behdad.org/ On Mon, Sep 4, 2023 at 3:47 PM Behdad Esfahbod <beh...@behdad.org> wrote: > 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 >
