Re: [ft-devel] Position Independent Port of FreeType2

[Mickey Gabel]

Here is an updated (probably final at this point) case study.
This one contains the previous modifications for autofit, as well as 
modular macros and modifications for module/renderer/driver definitions.

The diffs were generated with "diff -rupN <FT2 version> <my version>" 
from 2.3.8 and then zipped.

Some points:
------------
* For modules/renderers/drivers classes, instead of manually creating 
the structures, a macro is used to define the structure, or a pair of 
constructor/destructor functions instead for PIC builds.

* Note that the old module class symbols are gone in PIC builds. 
Instead, if the user needs module x, they must call FT_Create_Class_x 
(for example instead of ft_smooth_renderer_class, they must call 
FT_Create_Class_ft_smooth_renderer_class() and use the allocated pointer).

* The pointers allocated with FT_Create_Class_x can be used normally 
with Add_Module, etc.

* It is up to the user to release those pointers using FT_Destroy_Class_x.

* FT_Add_Default_Modules can be used normally. The library will keep 
track and release those modules when FT2 is released.

* Basically everything is backwards compatible, users shouldn't need to 
modify code.

* The idea is that at least for most modules, all previously global data 
can now be safely moved into the module's record (for example, to 
FT_Autofitter). The initialization of this "constant global" data can be 
done during module initialization.
However, I can't figure out how to get there from the various functions 
inside a module :(
As you can see, autofit still stuffs its own data into FT_LibraryRec, 
but this isn't very good.
Help?

* in ftrend1.c there appears to be a hack that checks a pointer directly 
(instead of having two different functions for two different classes). I 
had to modify it to another hack (check the number in the module's name.

* I feel that the module definition macros are not hard to use, and 
their impact on the code is minimal. The real work is moving data around 
INSIDE a module.

* The changes in autofit (specifically afglobals.c) are a good (I hope?) 
example of the sort of "deep" change to one file/module.

* The sweeping changes to the modules definition (which touch every 
module) are a good example (maybe?) of systematic, "wide" changes that 
would affect all/most existing and future modules.

* I only updated some of the modules, not all of them (see ft_module.h). 
Other modules might not compile when FT_CONFIG_OPTION_PIC is defined.

* As before, some of the changes to fstdlib.h and ftoption.h are related 
to the fact that I am using a custom build.

My questions for FT2 people:
----------------------------

1) What do you think? Would you accept this scheme into FT2, as a 
standard part? Would you accept something else?

2) Any suggestions for improvement?

3) So far I have converted the basic module/renderer/driver interface, 
and most of the autofit module.
I am not familiar with the insides of FT2, so can you sort of 
guesstimate how much of the conversion work I already did? 1%? 2% ? 5%? 
10%? 20%?
Is there a particular nasty case you can think of? Some module that uses 
a lost of function pointers or complex structs with a lot of 
interdependent pointers? (sfnt/sfdriver.c seems to contain a large 
function table, for example).


Thank you for your help,
        Mickey

Mickey Gabel wrote:
> Here is a diff (generated with "diff -rupN <FT2 version> <my version>" 
> from 2.3.8 and then zipped) for a small test case.
>
> Important notes:
>
> 1) Please concentrate on the changes to the autofit module 
> (src/autofit). Don't pay too much attention to anything outside it. For 
> example the changes in src/base are not exactly what I propose to do.
>
> 2) These diffs include the changes for our own custom build version, so 
> changes in include/freetype/config can be mostly ignored (except the 
> actual definition of FT_CONFIG_OPTION_PIC). They are included for 
> completeness.
> (for example, some modules are removed in my version)
>
> 3) Please also see my previous email from yesterday, with more 
> high-level ideas of the change.
>
> Any feedback is greatly appreciated!
>
> Thanks,
>     Mickey
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel

pic_diffs_02.zip
Description: Zip compressed data