Re: cairo_font_face_t not freeing

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>> [email protected]
>>> https://lists.cairographics.org/mailman/listinfo/cairo
>> --
>> cairo mailing list
>> [email protected]
>> https://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo