[ft] Cache sizes

[Daniel Wressle]

Salutations,

I was summoned to try to debug some really erratic and seemingly random issues 
we had with our font rendering. After many Red Bulls and debug output added
to both our code and the FreeType c-code I managed to figure out why most of 
them was occuring, but I do not understand why.

In short, as soon as we have more faces or sizes than the cache will allow, 
default being 2/2 as you already know, then strange things happens. First of all
we receive face object where the size pointer is NULL. This causes our 
GetKerning routine to fail, since there is no size data to work with. This will 
not occur if
we increase the size of the cache.

Q1: Are we doing something wrong? I would assume that the cache/MRU in FT would 
discard the least used node and then insert the new one, and hand us that. Why 
are we 
getting face objects with NULL size pointers when this happens? Have I 
misunderstood something? The easy solution is to just crank up the size of the 
cache but before
we do that I would like to know that we are not grossly misusing the whole idea 
of the cache.

Q2: The 2/2 defaults seem awfully low, but the manual and most information I've 
come across seem to agree that the cache should not be increased unless 
absolutely required. I guess the outcome of Q1 will decide that in our case, 
but what is  your experience when it comes to these numbers?

To my limited experience and knowledge it would seem a waste to even have a 
cache if we have to make it at least as big as all our faces and sizes 
combined, kind of like making your browser cache big enough to store the entire 
contents of the Internet.

I am assuming that I am missing out on something here. It is quite possible 
that we are doing something wrong on our end but I have verified that the size 
pointer is indeed NULL  using printfs in the FreeType code and that the font we 
are using is the same one as when we just increase the cache and stuff 
works<TM>.

I will keep on investigating this matter but I thought I would consult this 
mailing list just to make sure I am not overlooking something blatantly obvious.

King Regards,
Daniel