Re: Notes on Pango Xft backend

[Keith Packard <keithp keithp com>]

Around 14 o'clock on May 28, Owen Taylor wrote:

>  FcFontSetMatch: ~2 ms
>  FcFontSetSort:  ~10 ms
> 
> But in this case particular case (matching the "Sans" alias), I'd have called 
> FcFontSetMatch 8 times, so FcFontSetSort does end up ahead by 
> a small margin. 
> 
> As you might expect all the excess time is in doing the coverage computations.

Sounds like that operation could use a few speedups.

> The reason that Pango does it is that Pango does not keep font objects
> around persistantly; it looks them up from PangoFontDescription 
> as needed; so you could get bad thrashing effects without keeping
> some up.

I thought as much; given that Xft already has caches for fonts, it makes 
some sense to add this closed-font cache to that; Xft will be busy 
throwing glyphs away from other fonts to keep memory consumption capped, 
it would be helpful to know which are not actually currently in use; Xft
could throw away glyphs (and faces) from those fonts in preference to the 
active fonts.

> > If you use FcFontSetSort, you can keep only the pattern around and 
> > regenerate it as needed.  That operation is (relatively) quick.
> 
> You mean the FcFontSetSort operation is relatively quick? Guess it's a
> matter of perspective ...So, even with any conceivable optimization, I
> think some sort of cache in front of FcFontSetSort will be needed.

Yes, a cache in front of that will be needed, but the a cache miss can be 
internally regenerated from just the original pattern.

I'd naively thought that the matching operation would dominate the
character set whacking; that's clearly not the case.  I expect you're 
seeing a spike from FcCharSetSubtractCount; FcFontSetSort isn't using that 
to compute the actual count, only to discover whether there are any glyphs
in the new font not present in the previous fonts.  I'll recode that
to use a boolean function; that won't change the algorithmic order, but 
should at least remove some of the gratuitous computation involved.

> FcPatternEqual got rid of a bad hack in Pango but seems to be
> significantly slower than the bad hack was. (I think the main
> difference being that the bad hack only cared about a subset of all
> the pattern fields.)

Sounds like we need a slightly different operation then, one which takes an
FcObjectSet to limit the comparisons.

> My guess is that the biggest memory chunk for values is the strings for all
> the keys; using a shared set of strings for these would be a definite
> space win. (Also, allows a big further speedup in FcPatternEqual by
> reducing string compares.)

I don't copy the key strings, and the compiler should make them all point
at the same object these days.  But, doing == instead of !strcmp would
obviously be a lot faster.  Note that the FcPatterns now sort their keys, 
so I'd need canonical identifiers that sorted in the right order.  That 
seems hard.

> Perhaps my presentation here was a little confusing. 

>  * Currently, we just get the pattern, and only open the font as  
>    necessary.
> 
>  * But patterns are a) big; b) slow to compare and hash, so we
>    might want to look for an alternative.
>  
>  * Is an XftFont a reasonable alternative to keeping around the
>    pattern? no, because it is *bigger* than the pattern and 
>    also forces an open of the font file.

Yes, I think we're talking at cross purposes here.  I didn't understand why
you want to convert patterns to XftFonts early, but I believe I now do.  I
think you want a canonical object that represents the font which would be
opened given a particular pattern.  That's represented by the pointer you
get back from FcFontSetSort along with the source pattern, together those 
generate the FcPattern passed to XftFontOpenPattern.

Would you like some (opaque) data structure that can be generated from 
this pattern that can be used generate and XftFont?  I would expose Hash 
and Equal operators for that structure, but it needs to remain opaque as I 
expect the set of values needed to rasterize a font will change over time.

> I think I'll still need to do one of:
> 
>  a) Limit the number of "PangoFontDescription => font set" 
>     lookups I store.
> 
> or:
> 
>  b) Have some way of limiting the number of separate sizes that I 
>     store.

Hmm.  We might find a way to discover patterns which are equal except for 
size -- store that "sizeless" pattern along with the list of point->
pixel size mappings.  Perhaps FcPatternEqual could take an "include" 
object set and an "exclude" object set?

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab