[Fontconfig] performance optimizations

[Lars Knoll]

On Tuesday 12 October 2004 23:34, Keith Packard wrote:
> Around 17 o'clock on Oct 12, Owen Taylor wrote:
> > There are certainly some things that are known slow - the fact that
> > all FcFontMatch operations involve a linear scan could be improved
> > by adding some hash table indices. (There's a bug in bugzilla about
> > that.) But I'm a little surprised of 1 million + strcmps if you
> > are working with a small number of fonts.
>
> I'm actually wondering how well we could do if we were closer to the CSS
> font matching spec; that might permit a heirarchical database split across
> family/style/size boundaries which could reduce the search space for a
> particular pattern.  Converting the unsorted search to one which can use a
> sorted (or hashed) set of family names should make things a lot faster.

For Qt we tried to model our font loader after the CSS model. If this would 
help fontconfig as well, I'm all for it.

> And, using some kind of canonical string set and pointer compares would
> eliminate all calls to strcmp past the API.

I was always wondering why the API uses strings for the identifiers at all. 
Wouldn't an enum as
enum FcIdentifiers { FC_FAMILY, FC_SLANT, FC_WEIGHT, ... }
fit the purpose as well, be typesafe and get rid of all string compares (and 
lots of defines in the header).

I know this is difficult now, as it would break compatibility, but maybe for 
the future.

> > That's partly because common toolkits (Pango and I think also Qt) have
> > higher levels of caching above fontconfig.

We need to do this currently. In some fallback cases we go through fontconfig 
directly to find a font to use, and this path is rather slow (esp. if you 
have a large number of fonts installed). 

> Which would be nice to eliminate somehow; duplicating the font data in yet
> another format is not helping performance here.  Not that the current
> fontconfig format is useful for Pango, but perhaps we could design
> something as a replacement for all three systems (Pango, Qt and
> fontconfig).

Possible, but we would still need to do some sort of caching of loaded fonts, 
as that is outside of the scope of fontconfig. 

Currently we still have some problems finding the right font needed to render 
e.g. a certain writing system through fontconfig. Esp. if we require open 
type tables (e.g. for arabic or indic languages), fontconfig doesn't always 
give the right answer.

Cheers,
Lars