[cairo] No proper way to free cairo_font_face_t

[Tobias Fleischer (reduxFX)]

 I had found out about these issues 2 years ago or so, and while some of
the font freeing issues were solved with my suggestions, the fundamental
problem with the fonts staying in cache and not getting released remained.
My only solution at that time was to write a custom patch for Cairo that
implemented the font_face_t and related manager objects differently for my
product, but this was a very specific one-off hack.
In short, I'd also love to have to see the font handling in Cairo and
underlying Freetype library overhauled and fixed, but can't work on it
myself due to time constraints.
Cheers,
Toby

On Thu, Jan 6, 2022 at 3:18 PM Vladimir Sadovnikov <sadko4u at gmail.com>
wrote:

> Hello!
>
> I'm writing here since I have a problem which is currently not resolvable
> for me.
>
> Consider we have a host GUI application which can load plugins which also
> can
> provide their own GUIs. This is not rare example since all Digital Audio
> Workstations (DAWs) work in such manner.
>
> Since each plugin is a shared object file, it can be loaded (when the
> plugin
> becomes activated) and unloaded by the host (when the plugin was removed).
>
> The main problem is when we try to load and use custom font in the plugin
> and
> uses the following scenario:
>
> 1. when starting UI, it calls FT_InitFreeType to create the FreeType
> library object.
>
> 2. it allocates custom fonts by calling:
>
>    a. malloc() to allocate the space for font file data.
>
>    b. FT_New_Memory_Face to create font face using the previously
> allocated font
> file data.
>
> 3. when drawing the text, it performs:
>
>    a. cairo_ft_font_face_create_for_ft_face
>
>    b. calls cairo_font_face_set_user_data to register user data associated
> with
> the font which:
>
>       - is additionally malloc()'ed
>
>       - holds the pointer to font file data which was malloc()'ed in 2.a
>
>       - holds the pointer to FT_Face font handle object.
>
>    c. selects the font by calling cairo_set_font_face
>
>    d. performs the drawing of the text
>
> 4. Now, the plugin becomes deallocated. There are couple of problems:
>
>    a. Plugin should dispose the FT_New_Memory_Face object created in 2.b
> and
> free() the memory allocated in 2.a and 3.b. But because it is cached as a
> cairo_font_face_t object, it can not do it until cairo_font_face_t will be
> removed from cairo font cache.
>
>    b. If we set up a destruction routine in cairo_font_face_set_user_data,
> then
> we can not perform dlclose() on the plugin's shared object handle because
> after
> unloading the shared object, the pointer to the cairo_destroy_func_t
> routine
> becomes invalid.
>
>    c. Plugin should release the FreeType library object by calling
> FT_Done_FreeType. The documentation says about FT_Done_FreeType: 'Destroy
> a
> given FreeType library object and all of its children, including
> resources,
> drivers, faces, sizes, etc.' If the font face becomes destroyed, the
> cached
> cairo_font_face_t object becomes invalid since it points to the disposed
> data.
>
>    d. If we avoid freeing some memory resources, the memory will leak and
> once
> the host will crash by out-of-memory cause.
>
>
> Currently I don't have any ideas of solving problems related to 4. Having
> possibility to evict the cairo_font_face_t object from cairo cache would
> be a
> good option but there is no way to do this at this moment.
>
> So I would like to see any comments or recommendations related to my case.
>
>
> Best,
>
> Vladimir
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20220106/337f273a/attachment.htm>