freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance


From: David Turner
Subject: Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
Date: Mon, 22 Jun 2009 14:53:24 +0200

As noted by other posters, FT_Init_Library is a convenience function. You may want to use FT_New_Library instead to provide your own custom allocator.

2009/6/22 Werner LEMBERG <address@hidden>

>> > both FT_New_Memory, and FT_New_Library (functions called within
>> > FT_Init_FreeType) are allocating memory, before I have a chance
>> > of setting the function pointers in FT_Memory..  To get around
>> > that I added an extra argument to the FT_Init_FreeType, which
>> > allows me to provide an FT_Memory structure, before any other
>> > freetype code is running.
>>
>> The `canonical' way is to replace ftsystem.c with something more
>> appropriate for your target platform.  For example, you can copy
>> the whole file, only replacing `FT_New_Memory' to fit your needs.
>> I don't see an immediate need to add new API functions -- you have
>> to convince me that the just outlined method doesn't work :-)
>
> Sure I could do that... but then what is the point of having the
> FT_Memory struct...it doesn't work as advertised, and in order to
> fix it you advise me to replace a file where I need to implement my
> own ft_alloc methods?

Well, advise...  What I do is rather like taking a stab in the dark
based on previous information :-)

> The changes I made, make the FT_Memory struct work at all times, not
> just after initialization, even in a DLL build....  What you propose
> doesn't fix FT_Memory, but will fix my problem if I implement it in
> a way that adds a dependency on the system I have for allocating
> memory, which is an undesirable dependency, or if I just strip those
> methods from freetype, and implement them locally and have the
> linker sort it out.. (in which case a DLL build won't work anymore).
> both methods seem architectural wrong to me... but I guess I'm alone
> in that...

I don't think so.  Your arguments sound convincing -- let's see what
David says.

> Anyway, again I really just wanted to 'notify' you of this, if you
> don't believe the changes make sense then don't take it, I'm
> perfectly fine integrating my changes over top every time I upgrade,
> which I hardly do anyway.... I just ran into this again when I took
> the 2.3.9 upgrade, and though I might as well be decent and
> contribute back...

Thanks for that!  Please always reply to the list too (even if you
aren't subscribed).


   Werner


_______________________________________________
Freetype-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype-devel


reply via email to

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