[ft] Clarification about FT_Init_FreeType in a multithreaded environment
Ulrich Eckhardt <ulrich.eckhardt <at> dominolaser.com>
2013-06-11 11:09:23 GMT
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.
**************************************************************************************
RSS Feed