Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Jan Alexander Steffens]

On Thu, Jan 14, 2016 at 12:29 PM, Werner LEMBERG <address@hidden> 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.