[cairo] Font rendering options

[Carl Worth]

On Thu, 07 Jul 2005 17:00:27 -0700, Keith Packard wrote:
> On Thu, 2005-07-07 at 18:57 -0400, Owen Taylor wrote:
>
> >  cairo_scaled_font_t *
> >  cairo_scaled_font_create (cairo_font_face_t     *font_face,
> >                            const cairo_matrix_t  *font_matrix,
> >                            const cairo_matrix_t  *ctm,
> >                            cairo_render_options_t options);
> 
> Yes, I think this the right place to break the abstract/specific font
> notion.

Agreed. Getting options from the surface and using options when
creating a cairo_scaled_font_t looks like the perfect architectural
answer for a rather tricky problem.

>         Carl and I chatted about this in regard to the internals of the
> metrics and image caching and decided that a cairo_scaled_font_t should
> be expected to be used with a single backend; in the case of X, with a
> single Screen. From an internals perspective, it would be nice in some
> ways to require this, but from an API perspective, that's messy.

For anyone interested, the direction we sketched out for this is to
move the caching of glyph metrics and images from a global cache to
per-scaled-font caches. (One issue this raises is being able to set a
global size limit on all this caching, but we can still do this in a
style similar to what Xft does.) A big benefit that comes from this is
that the glyph cache key is no longer a huge object identifying the
scaled font, etc. but is simply the glyph index.

Then, there are various little bits of per-glyph state that are
specific to particular surface backend. For example, the xlib backend
needs to note whether glyph images have been uploaded to the server
glyphsets, and the glitz backend needs to note the position of the
glyph image within a texture. Currently the implementation is using
hash tables to associate glyphs with the surface-backend-specific
data.

Instead of this, the plan we came up with is to put a single slot into
the glyph for surface-backend-specific data. It seems prohibitive to
make an extensible structure here, particularly since we couldn't
imagine a use case that would really require reusing a single scaled
font with multiple surface backends. But, we also can't prevent this
reuse, (or, more precisely, we don't want to clutter up the API just
to prevent this).

So, the simplest thing to do seems to be to let a surface backend
claim a scaled font for itself if it's the first backend to see
it. Then it can lodge its own data in the cached glyphs. If another
backend later sees the same font, it can still generate correct
results easily enough, but won't be able to take advantage of the
caching. Again, this wouldn't be a recommended thing to do, but I
don't see why it shouldn't work anyway, even if more slowly.

> >  - Naming specifics - cairo_render_options_t is a bit too 
> >    generic, but cairo_font_render_options_t is too long.
> 
> Could be cairo_font_options_t; I don't think that's too misleading.

That gets my vote too.

-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/20050708/74a9bdb0/attachment.pgp