[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add support for FT_Face cloning

From: David Turner
Subject: Re: Add support for FT_Face cloning
Date: Wed, 9 Feb 2022 01:37:40 +0100

I have specific worries about what is being proposed here:
Just like for multi-thread usage, the only correct way to deal with a mutable API is to either use locking of a single instance before doing any mutable operation (be it loading something, or changing some settings), or to create several FT_Face instances instead. This keeps an already complicated API manageable without introducing new failure modes.

However, it should be possible to implement a real "cloning" facility that could be used for safe multi-threaded and variable-fonts usage. As long as all read-only sharing is hidden from the client, it can be introduced progressively into the source tree.
What I mean more precisely:
  • An FT_Clone_Face() API that takes an input FT_Face instance and returns a new instance that has its own lifecycle (except that they will be children of the same FT_Library, and use the same FT_Memory allocator).
  • For the input stream, a way to either clone it, or share it safely between instances is needed, and should be provided as an argument to the function in some way. We could change the stream implementation used internally by the library to make this easier, or we could require the client to use FT_Open_Face() with a user-provided shareable stream for FT_Clone_Face() to work.
  • The initial implementation would simply re-open the face with the new stream, inefficient but completely safe. But this opens the door to identifying read-only data in the source face that can be copied directly to the clone, saving all the work required to load/validate/compute it.
  • Note that I wrote "copy" above, because for efficient and safe read-only sharing, atomic reference counting is required, which is not part of C99, hence not portable. However, it can be introduced as a separate step by defining the right abstractions (types and macros to operate on them). Essentially, we need the equivalent of std::shared_ptr<>, or the intrusive versions of it where the ref-count is at the start of the shared object, but in C99 instead. For platforms that do not support threads, just do non-atomic refcounts.
  • The most important part is being able to progressively increase the efficiency of the cloning process in a way that adds read-only sharing in an explicit way that is easy to control at review time, or when changing the library's internals.

Le ven. 4 févr. 2022 à 17:02, Werner LEMBERG <> a écrit :

> This proposal aims to take the best of both approaches by
> introducing a new function, `FT_Clone_Face`.  [...]

Excellent summary, much appreciated, thanks!

What we are mainly interested in is whether other users would going to
use the proposed API as advertised.  If yes, please say so.  Otherwise
it would be great if you could discuss problematic issues with
Tayyab's approach.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]