[Devel] new fixes

[David Turner]

Hello,

  I've commited the following improvements yesterday night:

   I. Memory debugger:

     there are now two new environment variables, named
     FT2_ALLOC_TOTAL_MAX and FT2_ALLOC_COUNT_MAX which are
     used, when FT2_DEBUG_MEMORY is set, to specify the
     maximum amount of heap memory or allocations number
     that the memory debugger should enforce.

     this is useful to stress the library in tight memory
     environment, and allowed me to remove a few annoying
     bugs (memory leaks) in various parts of the engine.

     (these got unnoticed until yet because they only occured
      under special conditions).


   II. Cache behaviour improvements in the case of out-of-memory
       conditions:

     some small parts of the cache have been seriously rewritten
     in order to behave correctly in tight memory environments.
     More precisely, the functions "ftc_cache_lookup" and
     "FTC_Lru_Lookup" will not blindly report FT_Err_Out_Of_Memory
     when they see it.

     Instead, they'll first try to remove one or modes from the
     cache or their list, respectively. It seems to work well
     but I'd appreciate if someone could test it itself. I have
     only played a bit with FT2_ALLOC_TOTAL_MAX to check things.

     Note that after 2.1.4 is released, it will certainly be
     interesting to think about ways to reduce FreeType's memory
     footprint (with methods previously discussed), as well as to
     introduce the ability to register "memory reclaim" functions
     that could be called when FT_Alloc cannot allocate enough
     bytes from the heap.

     This would allow the cache to work even more efficiently
     (i.e., currently, there is no way to remove elements from
     the FT_Face and FT_Size LRU lists when trying to allocate a
     new cache node). However, this kind of callbacks must be
     written with _great_ care because they introduce potentially
     horrible re-entrancy issues.


  III. Native TrueType rendering:

     I believe I have commited a fix to the TrueType "scaling" bug.
     However, I had not the time to test it, and would dearly
     appreciate if some of you could test it (preferrably on Linux)

     There is a footnote[1] in this message that tries to explain
     how this works, because there have been confusion on the
     recent changes..

If everything works well, I believe that we've got a good candidate
for 2.1.4


Best Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


[1]:
    1/ how FT_Set_Char_Size works:

       this function is implemented in "src/base/ftobjs.c" and
       begins by computing the character pixel sizes and
       corresponding scaling factors using a "default"
       algorithm that font drivers can over-ride if they
       provide the appropriate callback.

    2/ How did in work in 2.1.3 and before ?:

       in 2.0.9, this function did compute the character pixel
       size according to the requirements of native TrueType
       hinting, I'm speaking about rounding requirements here.

       the callback provided in src/truetype/ttobjs.c just
       re-computed the character pixel size _without_ rounding
       in the case where a specific bit flag was _not_ set in
       the font header, to conform with the specification.

       this "feature" however has never really been tested due
       to the lack of fonts that unset this bit.


     2/ What has changed since:

       the "default" computations have been modified in order
       to accomodate David Chester's blue scale patch (which
       requires un-rounded scaling factors to be really
       effective)

       the truetype callback has also been modified especially
       to recompute the pixel sizes and scaling factors according
       to the TrueType spec/rounding , as well as to not store
       these new values in the root metrics of the corresponding
       FT_Size object. Instead, the "new" metrics are stored in
       a hidden location (named here "metrics2") that are not
       available to the rest of the engine.

       however, there have been subtle bugs in this re-implementation,
       and I now hope that things are correct.