[cairo] No proper way to free cairo_font_face_t

Bill Spitzak spitzak at gmail.com
Thu Jan 6 18:04:53 UTC 2022


It seems a little odd to dlclose a plugin. Generally it is really difficult
to get rid of all the pointers to stuff in the plugin (the font destructor
callback being just one of many). And the user may well want to use the
plugin a second time.

On Thu, Jan 6, 2022 at 6:36 AM Tobias Fleischer (reduxFX) <
tobias.fleischer at reduxfx.com> wrote:

> 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/3349fbce/attachment.htm>


More information about the cairo mailing list