[cairo] First draft of font changes

[Keith Packard]

Around 12 o'clock on Jan 18, Owen Taylor wrote:

>  1. cairo_ft_lock_face(), like XftLockFace doesn't protect against
>     locking different fonts pointing to the same underlying file.

I like explicitly exposing locking shared among multiple threaded cairo 
users. It does mean that the locking granularity is quite large, and that 
application bugs can cause unlocked access to shared objects, but the 
alternative seems to be inscrutible locking semantics with concommitment 
deadlock joy.

This raises the larger issue about where else in the cairo API we should 
provide shared locking mechanisms.  Should we provide a cairo_lock/
cairo_unlock which libraries and applications can use to ensure 
single-thread access to cairo functions?

> 2. Pango uses face->generic.data in a FT_Face for storing a pointer
>    to its own data.

It sounds like we need cairo_font_t private storage then.  Should this be 
keyed in any way so that multiple private objects can be depended from the 
font?

>  3. The functions to create a cairo_font_t currently take a composite
>     scale (font matrix * ctm).

I'll let you decide who holds the separate object containing the font 
matrix; it doesn't matter that much within the cairo space.

>  4. Should cairo_font_glyph_extents() take only a single glyph
>     rather than a string of glyphs,

Yes, this is a necessary change given that the font object has no notion 
of user space.  It has the advantage of moving the complex piece of the 
metrics computation up to shared code instead of being almost duplicated 
in several font backends.

>  5. cairo_font_extents() needs to be added to go along with
>     cairo_font_glyph_extents().

There are other orthogonality issues in the API; we'll want to review the 
whole system at some point to make sure the cairo_t and per-object APIs 
are in sync.

>  6. cairo_ft_font_create_for_ft_face() takes a FT_Face object that
>     must be kept alive as long as Cairo is using the font.

This is equivalent to the FILE object in PS/PDF/PNG surfaces and should be 
solved in the same way -- the cairo_font_t can be 'finished' which 
releases the connection with the FT_Face without destroying the 
cairo_font_t object itself; further usage of that cairo_font_t is an error.

destroy notifiers considered harmful.

>  7. Should we get rid of cairo_font_scale_t and use cairo_matrix_t
>     always?

yes.  Assertions in the public API that the translate components are zero 
would catch potential bugs.

> 8. Right now, the the image glyph cache goes from

Issue 3) provides this uniqified object.  Would you create per-unique 
glyph caches?  Or continue using the global glyph cache?  The global cache 
has the advantage of being a bit easier to eject objects from, although 
I'm not sure it weighs larger glyphs more when selecting which to eject.

>  9. The code doesn't currently assert if you unlock more times than
>     you lock.

Asserts are good.  Should we have warning assertions for things like this?

> 10. ft_font_val_t currently contains a pointer to the FT_Library
>     object. However this always points to the same FT_Library,
>     so it's a waste of memory.

We should use a global and protect it with a mutex.

> 11. cairo_ft_font_create() doesn't actually try to open the font,

It should open the font, and might be able to now that we expose only 
pixel-size specific font objects through the public API.

We'll have to make the cairo_t code not load a font on create though.

> 12. When using the toy API, a font matrix from fonts.conf (the 
>     default does artificial oblique) will be ignored.

3), 8) and 12) all push for an internal pixel-size specific font object 
with a separate fm/ctm cairo_font_t object.  It seems like we have 
a strong push in this direction here.

/me ignores actual patch.

-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/20050118/55972a48/attachment.pgp