[cairo] [patch] caching, glyph, font, and glyphset patch
otaylor at redhat.com
Wed Sep 29 12:46:38 PDT 2004
bOK, started looking through your patch a bit. I ran out of steam/time
partway through, but some high level comments:
* For Pango, I'd really like the ability to be able to get metrics
from a font without having a cairo_t around. This basically means
moving some of the private cairo_font_t API public; in particular
* I'm distinctly concerned about performance from repeatedly doing
cache lookups. Unless I add another layer of caching, in order
to layout a 1 meg text file, Pango is going to have to call
_cairo_font_glyph_extents() 1 million times.
Making the glyph cache hold sized-font references rather than glyph
references and exposing the sized-font object seems like it
would be a significant win.
(no actual timing here, of course)
* I don't think it exactly works to have fonts reporting metrics
in device space when transformations that aren't pure scales
are in effect. This is because ascent/descent/advance/etc.
are defined relative to the fonts coordinate system.
There's also a problem, for shears in particular, of separating
out two components - shears used to artificially oblique a font
as compared to shears of the coordinate system in which layout
is being done.
* cairo_ft_font_create() is calling
FcConfigSubstitute/FcDefaultSubstitute/FcFontMatch. I need
a version that works from a fully resolved pattern, or
alternatively a more managed version of the FT_Face interface.
* The pixelsize of the font has two effects on fontconfig
- When selecting bitmap fonts, the pixelsize affects *which*
font file will be selected in some cases.
- The pixelsize can also affect rendering options after the
font is selected.
I'm not sure how these effects are handled in your framework.
If I pass in fully resolved patterns, I can simply create a
different cairo_font_t for each pixel size, but that seems
to be fighting the infrastructure.
* How do you see rendering options like antialiasing, hinting,
and so forth being handled? again I could just create a
different cairo_font_t, but if a cairo_font_t roughly
corresponds to a filename/font_index pair, then this is
perhaps a bit awkward.
* The _cairo_glyph_cache_primary/secondary_cache() implementations
look suspicious with the cast to (unsigned long)... won't
the matrix elements generally be smallish doubles?
* There are a couple of places like _image_glyph_cache_create_value()
where you do:
A) Perform operation that might allocate memory, and might fail
B) On failure check for allocated memory and if so, free it
I think it makes things a lot more readable if the convention that
failing operations cannot return allocated memory is followed
* The DPI values you are passing to FreeType are rather debatable.
Two interpretations could be taken:
- Pixels to physical units ratio
- Point size to pixels ratio
I think it's actually the latter not the former. But as it turns
out, the char size and dpi are *only* used in the combination
char_size * dpi in the current FreeType sources, so it's pretty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040929/fece0f5e/attachment.pgp
More information about the cairo