Hi Ben, I will try the dynamic heap allocations for the rendering buffer. This might be the largest of them, I think. In addition, this should help with the rendering speed when rendering complex shapes like https://fonts.google.com/specimen/Cabin+Sketch. Currently, FreeType makes several attempts until a sub-band can fit into a static stack buffer. We should be able to fit it into a dynamic buffer easily. I wonder if CabinSketch should be about as complex as we can tolerate and refuse anything much more complex than this. A lot of time-outs will be resolved...
Alexei On Thu, Aug 31, 2023 at 7:40 AM Ben Wagner <bunge...@gmail.com> wrote: > > I've been meaning for a long time to propose something like this. One (or > more) of those stacks is bigger than 50KB. While most desktop apps have > threads with large stacks (~xMBs) there are users that run many threads in > one process and force the stack size of the threads to be small (~xxKBs) to > enforce small stacks so that the stack memory stays hot. On macOS secondary > threads are also pretty small at 512KB. Calls to FreeType often happen deep > in some application layout code which often is taking up a bunch of stack > frames, so a sudden deep 50KB stack frame can be too big. > > In any event, I have seen these really big stack frames be an issue in > practice. I've so far generally been able to get around this issue but it > would be nice to not need the work arounds. I think a lot of people would be > happy if FreeType reduced the size of these stack frames. > > On Wed, Aug 30, 2023, 11:20 PM Alexei Podtelezhnikov <apodt...@gmail.com> > wrote: >> >> Hi folks, >> >> Found this patch from ReactOS >> https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/3rdparty/freetype/freetype_ros.diff >> >> Do you understand why they are so averse to large stack allocations? >> >> Thanks, >> Alexei >> -- Alexei A. Podtelezhnikov, PhD
