The _cairo_win32_scaled_font_backend version of show_glyphs collects
glyph runs to hand to ExtTextOutW until the y-offset changes, then flushes the
glyphs buffered so far. As each glyph is buffered, it also calculates and
buffers the dx value for the preceding glyph.
However, when it sees a change in dy and decides to flush, it should *not*
append an entry to the dx buffer, as this would be the "dx" of the previous
glyph, and instead the new start_x value will be used for the new glyph run
that's being collected. This bug means that after any vertically-offset glyph,
the remaining glyphs in the run will get incorrect dx values (horizontal
escapement).
Mozilla bug #475092
Specifically,
cairo_region_union_rect -> cairo_region_union_rectangle
cairo_region_create_rect -> cairo_region_create_rectangle
Also delete cairo_region_clear() which is not that useful.
Usually, rectangles are more useful than boxes, so regions should only
expose rectangles in their public API.
Specifically,
_cairo_region_num_boxes becomes _cairo_region_num_rectangles
_cairo_region_get_box becomes _cairo_region_get_rectangle
Remove the cairo_box_int_t type
- Initialize region->status in _cairo_region_create_boxes()
- Make _cairo_region_copy() actually return a region.
- Fix a bug where a NULL region could be dereferenced
Also add an assertion that the result of cairo_region_copy() is never
NULL.
Adds a new, fake, fontconfig font backend. Fontconfig can be disabled
using --disable-fc, in which case the toy text API wont find fonts and
the internal font will always be used.
Also defines the feature macro CAIRO_HAS_FC_FONT. The two fontconfig-specific
functions in cairo-ft.h depend on that macro now.
Jeff Muizelaar pointed out that the severe overallocation implicit in the
current version of the glyph cache is obnoxious and prevents him from
accepting the trunk into Mozilla. Jeff captured a trace of scaled font
and glyph usage during a tp run and presented his analysis in
http://lists.cairographics.org/archives/cairo/2009-March/016706.html
Using that data, the design was changed to allocate pages of glyphs from a
capped global pool but with per-font hash tables. This should allow the
glyph cache to have tight memory bounds with fair allocation according to
usage. Note that both the old design and the 1.8 glyph cache had
essentially unbounded memory constraints, since each scaled font could
cache up to 256 glyphs (1.8) or had a reserved page (old), with no limit
on the number of active fonts. Currently the eviction policy is a simple
random strategy, this gives a 'fair' allotment of the cache, but a LRU
variant might perform better.
On a sample run of firefox-3.0.7 perusing BBC news in 32 languages:
1.8: cache allocation 8190x, ~1.2 MiB; elapsed 88.2s
old: cache allocation 771x, ~13.8 MiB; elapsed 81.7s
lean: cache allocation 433x, ~1.8 MiB; elapsed 82.4s
