2009/2/23 Mike Moening <mi...@reteksolutions.com> > 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. > No you can't.
> 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. > Exactly. > That seems sub-optimal. > The eye is in the beholder. Allowing what you want would make the design of FreeType much more complicated and would also make it use more memory in all cases. And if your file is memory-mapped, you shouldn't have much performance degradation from using several FT_Library/FT_Face in parallel anyway; and each thread should go as fast as possible, without any potential for locking or contention. > I welcome suggestions on the fastest architecture to simulaneously retrieve > font metrics with multiple threads. > > Thanks, > > Mike M. > > _______________________________________________ > Freetype-devel mailing list > Freetype-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/freetype-devel > >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
