[cairo] font lifetime

Owen Taylor otaylor at redhat.com
Thu Jan 27 14:58:11 PST 2005


On Thu, 2005-01-27 at 11:55 -0800, Bill Spitzak wrote:
> I'm a little worried about the apparent design that exposes some sort of 
> "object" for each possible font transform.
> 
> It is highly likely that future graphics implementations will render all 
> letters larger than about 20 pixels by using the 3D hardware to 
> texture-map a single large (like 128x128) rendering of the letter 
> through an arbitrary transform, and will render sizes larger than 128 by 
> actually filling the letter shape using the path-filling mechanism. 
> Changing the transform will be absolutely free (in that drawing a letter 
> with a different transform takes no more time than drawing it again with 
> the same transform). I also suspect this will become the solution for 
> all transforms smaller than some minimum size, and all non-right-angle 
> rotations, any shears, and if screen resolution is raised to 180 dpi or 
> so, it will replace ALL rendering of characters.
>
> In this case trying to support some kind of object that remembers a 
> transform and pointer to internal font is going to be a big piece of 
> unnecessary overhead. It would be very bad if Cairo's design was 
> compromised by obsolete hardware designs.

cairo_font_t can be very light when appropriate. In the case where you
don't hint, all you need in it is a pointer to the unscaled font and
a copy of the CTM. I don't see it being a bottleneck.

> I would much prefer an API where you set the font using a string name, 
> and you set the font transform, and then you ask for font metrics. The 
> only assumption about the metrics is that if the same font and same 
> transform is used you get the same results. Otherwise you should ask 
> Cairo again. The Cairo implementation should do the necessary work to 
> cache this correctly, rather than punting it to higher levels.

The Cairo toy API is that way. The Pango API is set up that way. The
API being discussed here is low-level glue between Cairo and alternative
high-level APIs like Pango.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050127/3f397761/attachment.pgp


More information about the cairo mailing list