[cairo] Counting semantics of cairo_ft_scaled_font_lock_face

Carl Worth cworth at redhat.com
Mon Feb 12 10:24:21 PST 2007

On Sat, 10 Feb 2007 10:16:51 -0800, Carl Worth wrote:
> But, as is, this series is not ready yet as it introduces a
> backwards-incompatible change to the semantics of
> cairo_ft_scaled_font_lock_face.

As I said before, that change is not really an option.

So, stepping back a bit, the problem that I'm running into here is
cause by the mutability of cairo_ft_unscaled_font_t, (since it caches
a scaled FT_Face).

We've got good locking in place around the scaled_font now, so the
problems that the patch series is trying to address comes when two
different scaled fonts are sharing the same unscaled font and trying
to cache different information in it at the same time.

Can anyone tell me why that FT_Face shouldn't just be stashed up into
the cairo_ft_scaled_font_t instead?

And couldn't cairo_ft_unscaled_font_t just be eliminated in favor of
just using cairo_ft_font_face_t, (the mutual referencing between the
two is already making the code very difficult to manage).

And then, couldn't the generic cairo_unscaled_font_t be dropped
altogether? There are certainly no other font backends other than
cairo-ft that are using this.

In other words, couldn't all of this be made a whole lot simpler? Or
are there problems being solved with the current approach that I'm
just not seeing here?

Obviously, one thing the current code is doing is trying to limit the
number of simultaneously open FT_Face objects. How does the size/cost
of those objects compare to the size/cost of the glyph objects that
cairo is already caching? Is there a dramatic difference that
justifies the custom cache mechanism here, (which is what
cairo_ft_unscaled_font_t looks like to me). Is it possible that some
of the original motivation for the cairo_unscaled_font_t stuff doesn't
apply after later rewrites to the font/glyph caching code?

Can someone help me understand the best way to clean all this code up?
(or, maybe even better, just the quickest way to get fix the lack of
locking around the current contention over the mutable fields of

I'll keep whacking at this, but I feel I'm not the best informed as to
everything that's going on here.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070212/389605db/attachment.pgp

More information about the cairo mailing list