freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ReactOS: stack vs heap


From: Oliver Brunner
Subject: Re: ReactOS: stack vs heap
Date: Fri, 1 Sep 2023 08:19:18 +0200
User-agent: SquirrelMail

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 freetype for rendering of fonts
(thanks for that!) the problem with large stack allocations exist also
there. The problem is that the freetype library must live within the stack
size of the calling executable and the application might not expect such
large allocations from a library.

I decided not to send in any patches as AROS is not so widely used and my
patches are sufficient for AROS. I assumed this problem is not an issue
for anybody else. My patches use the native AROS memory allocation
functions so can't be integrated without rewriting, but they are trivial
(more or less just malloc/free).

I patched the following functions in freetype-2.10.4 which caused problems
on AROS:

src/autofit/afcjk.c:
In af_cjk_metrics_init_widths() hints[1] and dummy are quite big.

src/autofit/aflatin.c
In af_latin_metrics_init_widths() hints[1] and dummy are quite big.

src/autofit/aflatin2.c
In af_latin2_metrics_init_widths() dummy[1] is quite big.

src/autofit/afmodule.c
In af_autofitter_load_glyph() hints[1] and dummy are quite big.

I patched the AROS compiler code to monitor the stack usage of each
freetype function while running executeables and the rest of the freetype
code seems not to use much stack but I might not have covered every code
path while testing of course.

Regards

o1i
-- 
| Oliver Brunner | aros@oliver-brunner.de
| "o1i"          |




reply via email to

[Prev in Thread] Current Thread [Next in Thread]