Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
I wonder whether this code from FT_Init_FreeType (*alibrary)-version_major = FREETYPE_MAJOR; (*alibrary)-version_minor = FREETYPE_MINOR; (*alibrary)-version_patch = FREETYPE_PATCH; should be moved to FT_New_Library to make FT_Library_Version more generic. I suppose that you don't call FT_Init_FreeType at all if using FT_New_Library, right? Do you use FT_Add_Default_Modules to register all modules or do you specify them directly with FT_Add_Modules? I've done this now. Yes, we use FT_New_Library followed by FT_Add_Default_Modules. The original plan was actually to add modules manually, but why do more work :D I've documented this better. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
1) We have our own struct that contains both the ft library and an FT_Memory object. 2) We initialize the fields in the FT_Memory object so that our callbacks are called. 3) We call FT_New_Library and tell it to use our memory object. This is the first FT2 API call. // Initialize freetype2 lib-ft_memory.alloc= sf_FTalloc; lib-ft_memory.free = sf_FTfree; lib-ft_memory.realloc = sf_FTrealloc; lib-ft_memory.user = lib; ft_err = FT_New_Library( lib-ft_memory, lib-ft_lib ); I wonder whether this code from FT_Init_FreeType (*alibrary)-version_major = FREETYPE_MAJOR; (*alibrary)-version_minor = FREETYPE_MINOR; (*alibrary)-version_patch = FREETYPE_PATCH; should be moved to FT_New_Library to make FT_Library_Version more generic. I suppose that you don't call FT_Init_FreeType at all if using FT_New_Library, right? Do you use FT_Add_Default_Modules to register all modules or do you specify them directly with FT_Add_Modules? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
Hello, On Mon, Jun 22, 2009 at 5:21 PM, Mickey Gabelmic...@monfort.co.il wrote: Tom van Dijck wrote: We have had no problem using FT2 with our own allocators (we work on systems were malloc() and free(), and possibly dynamic allocation entirely, are not present) So either I am doing it wrong, or Tom van Dick is doing it wrong. a totally unintentional spelling error ;) I like it OMG! Sorry, man :) I totally didn't see that 'j' even after you pointed it out. Time to get new glasses... That's because the i and j actually form a digraph in the Dutch language (from which Tom's last name descends) and was probably rendered wrong on your screen: http://en.wikipedia.org/wiki/IJ_(digraph) That bug has been long fixed in FreeType, so upgrade it :-) Regards, -- Leon ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
Werner LEMBERG wrote: 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 :-) We have had no problem using FT2 with our own allocators (we work on systems were malloc() and free(), and possibly dynamic allocation entirely, are not present) So either I am doing it wrong, or Tom van Dick is doing it wrong. Here's what I do: 1) We have our own struct that contains both the ft library and an FT_Memory object. 2) We initialize the fields in the FT_Memory object so that our callbacks are called. 3) We call FT_New_Library and tell it to use our memory object. This is the first FT2 API call. // Initialize freetype2 lib-ft_memory.alloc = sf_FTalloc; lib-ft_memory.free = sf_FTfree; lib-ft_memory.realloc = sf_FTrealloc; lib-ft_memory.user = lib; ft_err = FT_New_Library( lib-ft_memory, lib-ft_lib ); I've always felt that this is the way it's meant to be used! It doesn't look like a hack, and everything is documented. Also it works :) Basically, if I understand correctly, what Tom asked is already there. There's no need to modify ft_system.c, or invent new API calls. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
I agree - I also have had no problem using custom allocators with FreeType 2. I have successfully used DlMalloc, and currently use a hybrid system comprising a fast-access pool of small blocks and a fallback to standard malloc and free. Graham Asher CartoType Mickey Gabel wrote: Werner LEMBERG wrote: 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 :-) We have had no problem using FT2 with our own allocators (we work on systems were malloc() and free(), and possibly dynamic allocation entirely, are not present) So either I am doing it wrong, or Tom van Dick is doing it wrong. Here's what I do: 1) We have our own struct that contains both the ft library and an FT_Memory object. 2) We initialize the fields in the FT_Memory object so that our callbacks are called. 3) We call FT_New_Library and tell it to use our memory object. This is the first FT2 API call. // Initialize freetype2 lib-ft_memory.alloc= sf_FTalloc; lib-ft_memory.free= sf_FTfree; lib-ft_memory.realloc= sf_FTrealloc; lib-ft_memory.user= lib; ft_err = FT_New_Library( lib-ft_memory, lib-ft_lib ); I've always felt that this is the way it's meant to be used! It doesn't look like a hack, and everything is documented. Also it works :) Basically, if I understand correctly, what Tom asked is already there. There's no need to modify ft_system.c, or invent new API calls. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 w...@gnu.org 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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
We have had no problem using FT2 with our own allocators (we work on systems were malloc() and free(), and possibly dynamic allocation entirely, are not present) So either I am doing it wrong, or Tom van Dick is doing it wrong. a totally unintentional spelling error ;) I like it Anyway, I guess you're right though, this simple yet elegant solution had simply not occurred to me, which is retarded The solution below seems to be exactly what I need and want to do, and I'm sorry for even asking the other thing. Tom. Here's what I do: 1) We have our own struct that contains both the ft library and an FT_Memory object. 2) We initialize the fields in the FT_Memory object so that our callbacks are called. 3) We call FT_New_Library and tell it to use our memory object. This is the first FT2 API call. // Initialize freetype2 lib-ft_memory.alloc= sf_FTalloc; lib-ft_memory.free = sf_FTfree; lib-ft_memory.realloc = sf_FTrealloc; lib-ft_memory.user = lib; ft_err = FT_New_Library( lib-ft_memory, lib-ft_lib ); I've always felt that this is the way it's meant to be used! It doesn't look like a hack, and everything is documented. Also it works :) Basically, if I understand correctly, what Tom asked is already there. There's no need to modify ft_system.c, or invent new API calls. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
Tom van Dijck wrote: We have had no problem using FT2 with our own allocators (we work on systems were malloc() and free(), and possibly dynamic allocation entirely, are not present) So either I am doing it wrong, or Tom van Dick is doing it wrong. a totally unintentional spelling error ;) I like it OMG! Sorry, man :) I totally didn't see that 'j' even after you pointed it out. Time to get new glasses... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
Hey,
Forgive me if this is the wrong address to mail to, or if I should have
simply filed this as a bug.
The Freetype library allows you to set the malloc/free/realloc methods in
case you want to override the default behavior...Normally this is done at
least as far as I'm aware by getting the FT_Memory handle, and set the
alloc, realloc and free function pointers
This is awesome, however FT_Init_FreeType is creating that structure by
calling alloc, which is not so awesome, because I want to control ALL
memory..
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.
I locally changed FT_Init_FreeType to:
FT_EXPORT_DEF( FT_Error )
FT_Init_FreeType(FT_Library* alibrary, FT_Memory amemory)
{
FT_Error error;
/* build a library out of it, then fill it with the set of */
/* default drivers.*/
error = FT_New_Library( amemory, alibrary );
if ( error )
{
return error;
}
(*alibrary)-version_major = FREETYPE_MAJOR;
(*alibrary)-version_minor = FREETYPE_MINOR;
(*alibrary)-version_patch = FREETYPE_PATCH;
FT_Add_Default_Modules( *alibrary );
return error;
}
FT_EXPORT_DEF( FT_Error )
FT_Done_FreeType( FT_Library library )
{
if ( library )
{
/* Discard the library object */
FT_Done_Library( library );
}
return FT_Err_Ok;
}
this serves my purpose, but is obviously not backwards compatible, so a mix
of this and old would be required if backwards compatibility is a
requirement...
or you can just ignore me, and I'll keep making the change locally, I just
thought this was good to report.
Tom.
PS: redefining
#define ft_scalloc calloc
#define ft_sfree free
#define ft_smalloc malloc
#define ft_srealloc realloc
is not a valid option, since that would require me to include header files
that have no relationship with freetype, and thus would add dependencies on
a library that has nothing to do with freetype.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Init_FreeType allocating memory before I get a chance to set the allocators.
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 Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
