[Bug 458169] [@font-face] implement downloadable font support on Linux

[bugzilla-daemon at mozilla.org]

Do not reply to this email.  You can add comments to this bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=458169





--- Comment #20 from Karl Tomlinson (:karlt) <mozbugz at karlt.net>  2008-12-02 19:56:52 PST ---
(In reply to comment #16)
> 6) Modifying cairo to not holdover unreferenced fonts with external
>    destroy_hooks.

(In reply to comment #18)
> It seems like option 6 is the way to go. Or perhaps
> 
> 7) add a cairo API to flush unreferenced fonts (or unreferenced fonts with
> external destroy_hooks)
> 
> Basically, it's an API bug for cairo to require external destroy_hooks to work
> indefinitely far in the future.

I think there are also performance reasons to only holdover fonts that are
likely to be used again, and if these fonts have no external references they
are not likely to be used again.  So cairo won't need an API to flush
unreferenced fonts, if the holdover mechanism takes this into consideration.

I think modifying cairo's holdover logic is probably the best solution in the
long term, but will require quite a reshuffle of data structures.  I've filed

https://bugs.freedesktop.org/show_bug.cgi?id=18857

(In reply to comment #16)
> 4) Find out the FT_Library that cairo is using from the FT_Face from
>    a cairo_ft_scaled_font_lock_face, and use that instead of using a
>    separate FT_Library.
> 
>    There is some appeal in using the same FT_Library as cairo rather than
>    having two identical FT_Librarys.  This approach would be making the
>    assumption that cairo won't "Done" its FT_Library until
>    cairo_debug_reset_static_data, but I can't think of a good reason why
>    cairo might change its behavior to do this.

I think this is going to be the best solution in the short term, as we
currently don't need to concern ourselves with libraries being unloaded.

Behdad suggested this same solution as I was about to mention it to him, and
said that the assumption here is safe.

Selected discussion on this from #cairo, with some edits to group threads more
closely:

<karlt> i using cairo-ft-font for fonts created from an FT_Face
        for font data in memory
<karlt> this means registering a destroy_func on the font_face
<karlt> the bit where this gets inconvenient is that the destroy_func
        may be called at any time
<karlt> due to the holdovers in the scaled font map
<karlt> this is particularly inconvenient for users of cairo-ft-fonts
        that are dynamic libraries (or modules) that want to be unloaded
<karlt> such libraries would need to keep a reference to themselves, and
(often)
        call dlclose on themselves when the last cairo_font_face is destroyed
<karlt> calling dlclose on oneself either involves relying on tail-call
optimization,
<karlt> or making dlclose a destroy func on the last cairo_font_face
        (during execution of its first destroy_func)

<Company> can't you put the destory func into something that i not a module?

<otaylor> karlt: I think you just have to choose a) make a copy of the data
          b) don't unload your module

<karlt> Company: that's what making dlclose a destroy func on the last
        cairo_font_face would be doing

<Company> kinda, yeah
<Company> if you assume the dlclose really is called as the later one of the
          destroy funcs

<karlt> Company: yeah, it would be added only after the first destroy func has
        already been called

<Company> can you add destroy funcs from destroy funcs?

<karlt> Company: i haven't checked

<Company> i'd guess you can't, but not sure
<Company> unloading libraries is a PITA anyway, because it invites lots of bugs

<karlt> otaylor: i'm not seeing how to release the copy for (a)

<otaylor> karlt: might be tricky, you could have a tiny library that stays
resident

<karlt> otaylor: possible
<karlt> but i'm wondering whether this complexity is necessary:
<karlt> the holdover scaled fonts are only useful if they might be picked up
again
<karlt> and if there are no other references to the font_face then they won't
        be referenced again
<karlt> s/font_face/FT_Face/ maybe

<karlt> i guess i'm imagining a possible implementation something like where
the
        unscaled_font (or maybe font_face) decides how many scaled_fonts to
holdover
<karlt> that way the unscaled font can release scaled_fonts that won't be
needed

<karlt> on a related note, the user currently has to keep a reference count to
        it's FT_Library so that it doesn't call FT_Done_FreeType before cairo
        has called the destroy_func on the last FT_Face
<karlt> is it worth considering added an api to cairo-ft-fonts so that the
        user can use cairo's FT_Library?
<karlt> and does anyone know if there is significant memory associated with
        have extra FT_Librarys in existence

<behdad> messy stuff
<behdad> karlt: actually
<behdad> I don't know how come no one added ref counting to freetype

<karlt> yes, that would be nice

<behdad> as for getting to cairo's FT lib, just create a toy scaled font
         or something and get the lib out of that

<karlt> cairo's FT_Library is kind of available through
        cairo_ft_scaled_font_lock_face, and face->glyph->library

<behdad> yeah

<karlt> is it safe to assume that modifications to cairo won't choose to Done
        the FT_Library before reset_static_data?

<behdad> karlt: yes

-- 
Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.