Re: ReactOS: stack vs heap

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 <[email protected]> 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 <[email protected]> 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