[ft] Clarification about FT_Init_FreeType in a multithreaded environment

[Ulrich Eckhardt]

Greetings!

I'm currently making a few tests with the goal of reading vector fonts 
for use in laser marking. For that, I only need the outline, not any 
bitmap outputs. As far as the raw functionality goes, FreeType provides 
the required information, there are a few questions open though...


The documentation for FT_Init_FreeType says "For multi-threading 
applications each thread should have its own FT_Library object." and I'm 
wondering how to understand this sentence. Is this meant as "don't 
access FT_Library objects concurrently from different threads" or does 
every thread have to create its own library instance and I can't move 
objects between threads? I assume the former, but I'd like to clarify 
that first.

The reason I ask is the way I'm currently loading fonts. Our system is 
based on MS Windows CE5 and it is very restricted concerning memory. For 
that reason, I have a central repository that manages loading fonts on 
demand and unloading on memory shortage. However, this code is called 
from multiple threads (with a mutex, of course), and having one library 
per thread kind-of defeats the purpose of sharing data.


What I would create is:
1. One central instance of the libary (FT_Library), guarded by a 
"library" mutex.
2. A cache of FT_Face instances, each guarded by its own "face" mutex.

When rendering text, I would
1. Lock the library mutex.
2. If the faces is not cached, load it now and store it in the cache.
3. Then, lock the face mutex and release the library mutex.
4. Load the glyphs and render their outlines.
5. Release the face mutex.

My question in that context is whether the two-level approach to locking 
works, i.e. if I can call FT_Load_Char() and FT_Outline_Decompose() on 
the face while some other thread calls FT_New_Face() on the library. If 
not, could I get the above level of separation if I had one library 
instance per face? What is the overhead of creating a library instance?


BTW: It would have helped me understand the FreeType API if every 
resource-acquiring function had their release counterpart documented. 
This is already done for FT_New_Memory_Face()/FT_Open_Face() and 
FT_Done_Face(), but what about FT_New_Face()? Also, what is still not 
completely clear to me is when I can use FT_Done_FreeType(). For the 
faces, it seems that they are reference-counted, but what about the 
library itself? Will an early call pull the library from under my feet?


Please CC me on replies, as I'm not subscribed to the mailinglist. I can 
read the archives online, but it's difficult to respond without breaking 
threads then.


Thank you for your time!

Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraï¿œe 75a, 22547 Hamburg, Deutschland
Geschï¿œftsfï¿œhrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlieï¿œlich sï¿œmtlicher Anhï¿œnge ist nur fï¿œr den 
Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte 
benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte 
Empfï¿œnger sein sollten. Die E-Mail ist in diesem Fall zu lï¿œschen und darf 
weder gelesen, weitergeleitet, verï¿œffentlicht oder anderweitig benutzt werden.
E-Mails kï¿œnnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
ï¿œnderungen enthalten. Domino Laser GmbH ist fï¿œr diese Folgen nicht 
verantwortlich.
**************************************************************************************