In the 2.3.8 documentation it states that each thread should have its own FT_Library object.
Currently we keep one FT_Library per FT_Face. We have a C++ wrapper object per font face which wraps these two together. We use FT_New_Memory_Face() to load the face into the object. Because the font files are rather large (several Megabytes) we leave the face open, so as not to re-load it every time we need to get metrics on a different glyph. Question: Can we safely use the stored FT_Face handle with other FT_Library instances? Assuming (per documentation suggestions) that we have a FT_Library per thread. The idea is to allow multiple threads to get glyph metrics by simultaneosly calling these methods: FT_Set_Char_Size() FT_Get_Char_Index() FT_Load_Glyph() Once we retreive the metrics we store each set of metrics in map hashed by glyph which is owned by the wrapper object. This map is protected by a lock of course. It seems to me, based on my understanding of the code, that there would be no way to allow each thread to access the metrics unless each thread calls FT_New_Memory_Face() and has its own handle to the face. That seems sub-optimal. I welcome suggestions on the fastest architecture to simulaneously retrieve font metrics with multiple threads. Thanks, Mike M.
_______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
