On Thu, Jan 14, 2016 at 12:29 PM, Werner LEMBERG <w...@gnu.org> wrote:
>> To you and your model of the world, these might "act globally on
>> many faces". To a fontconfig-using-, or cairo, or Chrome, or
>> Firefox, or Skia, or Android, or Qt, or any other large-enough
>> platform, there's no global setting, there's just per-face
>> configuration that needs to be enabled. If you push that to
>> FT_Library, that makes FT_Library thread-unsafe and bound to one
>> face at a time.
>
> I don't understand your reasoning. FontConfig, for example, doesn't
> provide an `FT_Library' object to a client that queries font
> information, AFAIK. An application has to call `FT_Init_FreeType' by
> itself, then deriving all `FT_Face' objects from the just created
> `FT_Library' object. Ditto for Qt (where a call to `FT_Init_FreeType'
> is hidden by an application's Qt initialization). How can this be
> thread-unsafe? What am I missing? Please provide a real-world
> example that helps me understand your concerns.
I'm not sure, too. Maybe applications mutex-protect FT_{New,Done}_Face
rather than use one FT_Library per thread, as the documentation
recommends?
Altering any settings on FT_Library while other threads use FT_Faces
created from it causes data races, unless you protect all the calls on
the Library *and* the Faces with the mutex.
Even then, while you might not get any corruption, you still have a
shared rendering state that might get changed unexpectedly.
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
