> Thanks. One thing I don't understand, is the "+ 2" in the code below:
>
> AF_LatinBlue blue_sorted[AF_BLUE_STRINGSET_MAX_LEN + 2];
>
> for ( i = 0; i < axis->blue_count; i++ )
> blue_sorted[i] = &axis->blues[i];
>
> If that + 2 is correct to be there, then we need a similar
On Mon, Sep 4, 2023 at 8:27 PM Werner LEMBERG wrote:
>
> > Upon further investigation, I think my proposed change is correct.
>
> Thanks a lot, committed!
>
Thanks. One thing I don't understand, is the "+ 2" in the code below:
AF_LatinBlue blue_sorted[AF_BLUE_STRINGSET_MAX_LEN + 2];
> Upon further investigation, I think my proposed change is correct.
Thanks a lot, committed!
Werner
Upon further investigation, I think my proposed change is correct.
behdad
http://behdad.org/
On Mon, Sep 4, 2023 at 4:26 PM Behdad Esfahbod wrote:
> 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.
>
> be
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 wrote:
> On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod wrote:
>
>> On Sat, Sep 2,
On Mon, Sep 4, 2023 at 3:39 PM Behdad Esfahbod wrote:
> On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov
> 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 tr
On Sat, Sep 2, 2023 at 12:31 AM Alexei Podtelezhnikov
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_i
>
> 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
> (52
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
> >> https://
>> 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
>> 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 sev
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 fr
> 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 att
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
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
en
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
16 matches
Mail list logo
