Hi Alexei,
Alexei Podtelezhnikov schrieb:
> Do you understand why they are so averse to large stack allocations?
I am a long time lurker on this list just for this reason ;-). AROS (an
AmigaOS3 API compatible OS) has inherited the not automatically growing
stack of AmigaOS. As AROS mainly uses
On Fri, Sep 1, 2023, 9:45 AM Alexei Podtelezhnikov
wrote:
>
>
> >> 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
> >>
>> 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
>> Perhaps a hybrid approach is the right one: Use the current
>> infrastructure up to a certain size, being as fast as possible because
>> dynamic allocation overhead can avoided, and resort to dynamic
>> allocation otherwise.
>
> FreeType is not shy about allocating buffers to load a glyph. This
>
> 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
>
