Hello Owen,
>
> Actually this reading of the code is not correct ... Pango only
> keeps alive a PangoXftFont/XftFont for
>
> - Any fonts currently referenced by the application
> - The last MAX_FREED_FONTS (16) that are not otherwise referenced
>
> Now whether this is best way to do caching is another issue, but
> it doesn't just keep arbitrary numbers of XftFont/FT_FACE objects
> around.
>
Well, well, I've just done a grep on "XftFontClose" on the whole
Pango sources, and it shows that this function is only called in
_one_ place, line 465 of "pangoxft-fontmap.c".
Unfortunately, this correspond to the case where the function
"pango_xft_load_font_map_load_font" fails to properly set the
character map on a new XftFont/FT_Face object..
In other words, successfully opened XftFont objects seem to never
be freed explicitely by Pango !! Is this a bug, or did I miss
something ??
(It seems you're correct for pangoft2-fontcache.c though..)
> (The reason for the caching is that, for example, when laying out
> the text in a GtkTextView object the code will load the fonts
> for a paragraph, do the layout, free the fonts, load the fonts
> for the next paragraph, and so forth, so if you don't have cache,
> this can get very inefficient. If you have more than 16 fonts
> per paragraph, of course, it gets very inefficient now, but you
> probably deserved that...)
>
A cache is nearly always necessary in order to re-use
metrics / images and tables as quickly as possible during
text layout. However, binding the cached "nodes" to an opened
FT_Face object is not a good idea and can seriously hurt your
memory footprint.. and I'm afraid that's the way
it's currently implemented by libXft+Pango's design.. :-(
If Keith implements lazy binding of FT_Face objects to
XftFonts, this problem is seriously reduced though..
Cheers,
- David
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
