[cairo] Counting semantics of cairo_ft_scaled_font_lock_face

[Carl Worth]

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

An easier step seems to be just moving all of the mutable stuff to
cairo_ft_scaled_font_t where it fits more naturally anyway, (it only
changes based on the scaling anyway).

At first glance, the most trivial version of this will have two
impacts:

* Calling FT_New_Face more often as two different scaled fonts that
  share the same unscaled font will now each have their own FT_Face
  rather than just sharing the same FT_Face and changing its
  transformation.

* Holding on to FT_Face objects longer, (not getting rid of them until
  the scaled_font falls out of its own cache).

The work to remove those impacts probably wouldn't even be too
severe. Though it's also not obvious to me if the impact is all
negative. For example, might it not be better to maintain two separate
FT_Face objects rather than thrashing back and forth with
FT_Set_Transform on a shared FT_Face?

Again, I would be quite glad if people with more experience than I
have would help steer me in good directions with this stuff.

I suppose one thing we need is a text-using perf case that has font
usage patterns consistent with some real-world test cases---perhaps
something like rendering every page in a non-trivial PDF document?

-Carl
-------------- 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/4da4ac76/attachment.pgp