[cairo] Notes from Pango/Cairo integration

[Keith Packard]

Around 15 o'clock on Jan 9, Owen Taylor wrote:

> At one level that's not avoidable ... doing fontconfig matches is
> expensive so it's not going to be suprising that Pango has a cache
> of "PangoFontDescription => list of resolved patterns", and 
> Cairo has a cache family/slant/weight => cairo_unscaled_font_t".

Aside from making cairo_t creation fast when fonts aren't involved, the 
performance of the toy API shouldn't be a significant concern.  We should 
look into simply eliminating this cache.

> The question is then whether it makes sense to have any common
> caches that bring things together at a lower level? The minimum
> would be to have a cache like Xft where all fonts for the same file 
> on disk share the same FT_Face.

Same file and index (for .ttc files).  Xft caches (essentially) resolved 
patterns to scaled fonts.  Perhaps we should do the same here?

> Finally, I'm concerned that the way cairo_glyph_extents is
> handled in the FreeType backend is going to be slow; having a global 
> glyph cache means that glyph lookups involve fairly complicated hash
> logic (*).

The alternative is the messy logic in Xft to eject glyphs from the cache.  
I'm not sure which is worse.

> (*) _cairo_glyph_cache_hash looks broken ... any matrix that scales
> down will collide with any other matrix that scales down.

Yes, I noticed that as well.  Given that the hash values don't escape the 
application, and given a homogenous datatype in the struct, it seems 
portable to me to just hash the bytes of the matrix directly.  I use a 
crc-32 hash in such situations myself; it's not cryptographically secure, 
but is generally better than the typical 2-second hash algorithm.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050109/7962bad8/attachment.pgp