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

[Behdad Esfahbod]

On 16-01-14 02:03 PM, Jan Alexander Steffens wrote:
> 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?

When writing libraries, it's desirable to create objects that can be used by
threads other than the thread that created them.  Because of this limitation
in FreeType, libraries relying on FreeType also have to either expose the same
restriction, or do lots of locking, or to create one FT_Library per FT_Face.


> 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.

Right.  But I already noted that no setting in FT_Library other than the LCD
filter is useful for most rendering systems.  The work I did a year ago makes
using FT_Library from multiple threads almost possible:


https://github.com/behdad/freetype/commit/4eff854c27728aa21751af2c4f3c5f0afe83ebd1

> Even then, while you might not get any corruption, you still have a
> shared rendering state that might get changed unexpectedly.

This "shared rendering state" you keep talking about is exactly what I'm
objecting to. :)

-- 
behdad
http://behdad.org/