[cairo] cairo_font_face_t not freeing

[Bill Spitzak]

I think I understand. I don't know the Windows api, but I am guessing
that the function that returns an hfont returns a new one on each
call, there is no cache or reuse. The client program is expected to
manage the set of hfonts they are interested in, which leads to this
difficultly as you can't do this if Cairo will crash if you delete an
hfont and you cannot easily figure out when Cairo is not using it any
more.

It does seem like the ideal solution would be a "forget about this
font" to Cairo that would remove that (and only that) font from the
mru_cache. I'm not sure what it should do if any contexts have the
font set, possibly it should force those contexts back to a default
font. It could also cause an error which probably means you get a
crash like now if you delete the hfont.

When I asked about the cache I actually meant what you are calling the
mru_cache. The question was whether the mru_cache serves any purpose
for cairo_win32_font_face_create_for_hfont, will it find an old font
for the same hfont from the mru_cache? If not then it seems an easy
solution would be to just not put any fonts created this way into the
mru_cache.


On Mon, May 22, 2017 at 4:59 AM, Fred Bca <fredbca21 at gmail.com> wrote:
> hfonts are not reference counted, and as far as I remember, cairo
> fonts created using this API will not destroy the hfont (and that's
> the expected behavior), hence the lifecycle issue (see the
> delete_scaled_hfont field). I think that's the only difference with
> other font faces, everything else is the same, including caching.
>
> Not adding these fonts to the cache would probably result in poor
> performance so I guess it is not an option. And the cache is not the
> problem btw: it's only the mru_font and the holdovers list. Maybe the
> font should be flagged as not available for the mru/holovers in the
> constructor, but this would require adding this option to all types of
> fonts.
>
> That's why a way to fix it is to avoid keeping a list of unused fonts
> in a mru/holdovers list or provide a simple way to flush it (to
> minimize the impact): if the lifecyle of system fonts is properly
> managed from the outside (making sure no font is kept in a context
> before freeing it), then there is no issue.
>
> The current behavior is just not compatible with the use of externally
> provided hfonts: either you do not free them and you have a leak, or
> you free them and you have crash, sometimes, not always.
>
> On Mac fonts are reference counted, so there is no crash. However if
> you do not use the toy API to create and manage fonts, you probably
> want to have control over memory and resources usage - also, depending
> on how the CGFont has been created, you may want to know exactly when
> it is released.
>
>
> On Thu, May 18, 2017 at 7:20 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> I don't understand how it even works as intended. What destroys the
>> h_font passed to cairo_win32_font_face_create_for_hfont when the
>> font_face is destroyed (for instance in the current implementation
>> when it is thrown out of the lru cache)? If it is done automatically
>> then there is no way your code can destroy the h_font as it may be
>> doubly-destroyed. If it is reference-counted then there should be
>> absolutely no problem with the current cache, you or that font library
>> can "destroy" the h_font all it wants. If, as you imply, it leaks,
>> then there is no way to fix this cleanly, and any solution would
>> require *ALL* programs, including "toy" ones, to maintain a callback
>> that says when an h_font is no longer in use.
>>
>> Can an h_font be shared between mulitple font_face? What if you use it
>> twice in two different cairo contexts?
>>
>> Does cairo_win32_font_face_create_for_hfont find a previous use of the
>> same h_font in the cache? If not then it seems plausible that use of
>> this constructor function would also indicate that the font should not
>> be put in the cache in order to fix this problem.
>>
>> On Thu, May 18, 2017 at 5:22 AM, Fred Bca <fredbca21 at gmail.com> wrote:
>>> This looks like the issue that I encountered last year with the
>>> holdovers cache. The cairo font cache works fine and is necessary for
>>> performance, BUT it also keeps a list of fonts that have been recently
>>> released which are not used anymore (+ a most recently used font).
>>> While this can be useful at the application level, I
>>> don't think that it belongs to cairo as is, since it keeps some fonts
>>> alive forever, with no control over it as far as I know.
>>>
>>> More information and a patch for a quick fix can be found here:
>>> https://lists.cairographics.org/archives/cairo/2016-April/027349.html
>>>
>>> It would be nice if we can come up with a solution to fix this that is
>>> accepted by the community. A compile-time option or runtime API to
>>> disable / control this behavior for example?
>>>
>>> On Sun, May 7, 2017 at 4:13 PM, Louis M <prog at tioui.com> wrote:
>>>> On 05/05/2017 10:42 AM, Uli Schlachter wrote:
>>>>> I'm not completely sure how this cache works, but I doubt that it "keeps
>>>>> to things" indefinitely. It might even just be a most-recently-used
>>>>> cache so that it only ever keeps one font alive - I'm not sure.
>>>>
>>>> Ok, Thanks. This is reassuring. I will try to do some testing.
>>>>
>>>> Good day,
>>>>
>>>> Louis M
>>>> --
>>>> cairo mailing list
>>>> cairo at cairographics.org
>>>> https://lists.cairographics.org/mailman/listinfo/cairo
>>> --
>>> cairo mailing list
>>> cairo at cairographics.org
>>> https://lists.cairographics.org/mailman/listinfo/cairo
> --
> cairo mailing list
> cairo at cairographics.org
> https://lists.cairographics.org/mailman/listinfo/cairo