[cairo] Counting semantics of cairo_ft_scaled_font_lock_face

[Owen Taylor]

On Mon, 2007-02-12 at 10:24 -0800, Carl Worth wrote:
> 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.

I don't think we do have locking around the scaled font. Sure, we lock
on the scaled font when doing things *inside* cairo, but we also return
out the FT_Face via lock_face(), and we don't have any protection then.

The patch that was proposed recently made lock_face() actually get the
scaled font mutex; that would certainly be one way of handling it,
if we used a recursive lock (and building a recursive lock on top of
non-recursive locks isn't that hard. GLib can be used as a source
for the technique to do it.) But I'm not sure it's the best thing
to do; leaking a cairo internal lock like this out into the caller is
an invitation for deadlocks.

A better thing to do  might be to simply open another FT_Face if the
one we have is already in use.

> 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.

The public cairo_unscaled_font_t is meant to be there for font
embedding; the idea is that you only have to embed an unscaled font
once. I don't know what was done about this when was embedding support
was done for non-FreeType platforms.

> 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? 

My experience is that it's generally a lot cheaper to rescale a FT_Face
than to open a new one. There has been a lot of work done to reduce the
per-face allocated (and not mapped) memory, so my experience may be
out of date as far as FreeType goes. If we ignore FreeType issues,
there is still a Pango issue. Pango parses the fonts OpenType tables
once per FT_Face and caches them on the FT_Face, so if you start opening
a FT_Face per size, Pango performance is going to go through the floor
and memory usage is going to go through the roof.

						- Owen