[cairo] Font analysis

[Carl Worth]

On Fri, 18 Mar 2005 13:11:34 -0500, Owen Taylor wrote:
> Rather than replying to specific items in Carl's mail, let me start
> from scratch and try to define the objects that we are talking about.

Owen,

Thanks for this excellent set of definitions and a summary of the
issues. It's much easier to work from than what I had.

>     For remainder of this email, this will be called a FontName.
>
>     For the remainder of this email, this will be called
>     a ScaledFont.
> 
>     For the remainder of this email, this will be called
>     a FontFile

Excellent. It's good to have solid terminology to work with.

> 1. Don't expose a ScaledFont object, but use a FontName + scale
>     everywhere in the public API. This is more or less how the
>     older cairo API was set up, though the right set of FontNames
>     wasn't available. With fixed FontNames it works better, but
>     falls over on two counts:

I like this proposal the best I think.

>      - Performance. For every glyph we want to measure, we have
>        to do a full lookup. Even with the right hash tables, this
>        is prohibitive.

I don't understand this point. Given a FontName+scale, cairo can
lookup and cache the ScaledFont in cairo_t. So, the lookup overhead is
"for every time the FontName or scale changes", not "for every
glyph". In your "million glyphs per second" requirement, how many
changes to the ScaledFont should we be able to handle?

I know you said something once about definitely not wanting to go
through cairo_t to get metrics, but I don't recall what the specific
concern was there.

It should be a fairly simple to document which cairo function calls
change the un-exposed ScaledFont that cairo is using, (anything that
changes the FontName, the FontScale, or the CTM). So, an application
should be able to know when it can rely on the underlying platform
font object it got from cairo, and when it needs to get a new one,
right?

>      - Inability to reference the underlying platform font objects.
> 
>        Currently we have cairo_win32_font_select_font()/done_font()
>        for Win32 and cairo_ft_font_lock_face()/unlock_face()
>        for FreeType. These return scaled objects for the
>        underlying backend, and so need scaled objects in the
>        FreeType API.

Couldn't we just add similar font-backend-specific functions to the
cairo_t? I don't see why it would be unable to return the platform
font object it's using. (We would have a new naming problem, as
currently all font-backend-specific functions are on cairo_font_t, not
cairo_t, but that doesn't seem like a showstopper).

> 2. Make ScaledFont objects mutable.

This sounds like what cairo_t would use internally for (1), but
exposing it causes the problems you outlined.

> 3. Expose a ScaledFont object, but only allow setting a FontName
>     on a cairo_t. So, Pango would when creating a PangoFont
>     would store the current scale, create a FontName, then
>     create a ScaledFont for the FontName and scale. The
>     PangoFont holds references to both ScaledFont and FontName.

This also sounds quite workable to me.

>     This obviously has some performance impact, though
>     per-string overhead when drawing is *much* better
>     than per-glyph overhead when measuring.

Why is there any performance impact here? Can't pango just not re-set
the FontName if it hasn't changed since the last drawing operation and
avoid the lookup overhead?

> 4. Allow setting either a ScaledFont or a FontName on a
>     cairo_t. If both are set, the ScaledFont overrides the
>     FontName. scale_font() transform_font() don't affect
>     the ScaledFont.

This is basically what we have in CVS now, and I don't like it.

> 5. Allow setting either a ScaledFont or a FontName on a
>     cairo_t. If a ScaledFont is set and the scale or
>     font_matrix don't match the CTM, linearly scale the
>     outlines or bitmaps to match the CTM.

This is what I proposed to fix what's in CVS, and you don't like
it.

I'm perfectly happy with either (1) or (3) from the point-of-view of
API cleanliness. The downsides of those proposals are mostly(1) or
exclusively(3) related to performance. And, unless I'm still not
grasping part of the problem, it seems like we should be able to get
the overhead down to per ScaledFont change, which I would expect to be
quite manageable.

-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/20050318/74a9875d/attachment.pgp