<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 6, 2022 at 6:36 AM Tobias Fleischer (reduxFX) <<a href="mailto:tobias.fleischer@reduxfx.com">tobias.fleischer@reduxfx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
<div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Cheers,</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Toby</div>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 6, 2022 at 3:18 PM Vladimir Sadovnikov <<a href="mailto:sadko4u@gmail.com" target="_blank">sadko4u@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
I'm writing here since I have a problem which is currently not resolvable for me.<br>
<br>
Consider we have a host GUI application which can load plugins which also can <br>
provide their own GUIs. This is not rare example since all Digital Audio <br>
Workstations (DAWs) work in such manner.<br>
<br>
Since each plugin is a shared object file, it can be loaded (when the plugin <br>
becomes activated) and unloaded by the host (when the plugin was removed).<br>
<br>
The main problem is when we try to load and use custom font in the plugin and <br>
uses the following scenario:<br>
<br>
1. when starting UI, it calls FT_InitFreeType to create the FreeType library object.<br>
<br>
2. it allocates custom fonts by calling:<br>
<br>
   a. malloc() to allocate the space for font file data.<br>
<br>
   b. FT_New_Memory_Face to create font face using the previously allocated font <br>
file data.<br>
<br>
3. when drawing the text, it performs:<br>
<br>
   a. cairo_ft_font_face_create_for_ft_face<br>
<br>
   b. calls cairo_font_face_set_user_data to register user data associated with <br>
the font which:<br>
<br>
      - is additionally malloc()'ed<br>
<br>
      - holds the pointer to font file data which was malloc()'ed in 2.a<br>
<br>
      - holds the pointer to FT_Face font handle object.<br>
<br>
   c. selects the font by calling cairo_set_font_face<br>
<br>
   d. performs the drawing of the text<br>
<br>
4. Now, the plugin becomes deallocated. There are couple of problems:<br>
<br>
   a. Plugin should dispose the FT_New_Memory_Face object created in 2.b and <br>
free() the memory allocated in 2.a and 3.b. But because it is cached as a <br>
cairo_font_face_t object, it can not do it until cairo_font_face_t will be <br>
removed from cairo font cache.<br>
<br>
   b. If we set up a destruction routine in cairo_font_face_set_user_data, then <br>
we can not perform dlclose() on the plugin's shared object handle because after <br>
unloading the shared object, the pointer to the cairo_destroy_func_t routine <br>
becomes invalid.<br>
<br>
   c. Plugin should release the FreeType library object by calling <br>
FT_Done_FreeType. The documentation says about FT_Done_FreeType: 'Destroy a <br>
given FreeType library object and all of its children, including resources, <br>
drivers, faces, sizes, etc.' If the font face becomes destroyed, the cached <br>
cairo_font_face_t object becomes invalid since it points to the disposed data.<br>
<br>
   d. If we avoid freeing some memory resources, the memory will leak and once <br>
the host will crash by out-of-memory cause.<br>
<br>
<br>
Currently I don't have any ideas of solving problems related to 4. Having <br>
possibility to evict the cairo_font_face_t object from cairo cache would be a <br>
good option but there is no way to do this at this moment.<br>
<br>
So I would like to see any comments or recommendations related to my case.<br>
<br>
<br>
Best,<br>
<br>
Vladimir<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>