We failed to cleanup the font face correctly after an allocation failure
during _cairo_toy_font_face_init() leading to memleaks and live entries
being left in the font-face hash tables.
As a fun itch to scratch, I've been fixing incorrect uses of the
contraction "it's" in comments within the mozilla source tree (tracked
in https://bugzilla.mozilla.org/show_bug.cgi?id=458167 ), and I ran
across 6 instances of this typo in mozilla's snapshot of cairo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adds an error code replacing CAIRO_STATUS_NO_MEMORY in one case where it
is not really appropriate. CAIRO_STATUS_INVALID_SIZE is used by several
backends that do not support image sizes beyond 2^15 pixels on each side.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The agreement on the mailing list was that returning NULL is the right
thing to do, and indeed the callers of _cairo_glitz_surface_create_similar
are prepared to receive NULL and return CAIRO_STATUS_INT_UNSUPPORTED in
that case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently glyphs are cached independently in each font i.e. each font
maintains a cache of up to 256 glyphs, and there can be as many scaled fonts
in use as the application needs and references (we maintain a holdover
cache of 512 scaled fonts as well).
Alternatively, as in this patch, we can maintain a global pool of glyphs
split between all open fonts. This allows a heavily used individual font
to cache more glyphs than we could allow if we used per-font glyph caches,
but at the same time maintains fairness across all fonts (by using random
replacement) and provides a cap on the maximum number of global glyphs.
The glyphs are allocated in pages, which are cached in the global pool.
Using pages means we can exploit spatial locality within the font
(nearby indices are typically used in clusters) to reduce frequency of small
allocations and allow the scaled font to reserve a single MRU page of
glyphs. This caching dramatically reduces the cairo overhead during the
cairo-perf benchmarks, and drastically reduces the number of allocations
made by the application (for example browsing multi-lingual site with
firefox).
The bounding polygon of the control points, defines the extents of the
spline. Therefore if the control points are entirely contained within the
current path extents, so is the spline and we do not need to evaluate its
tight bounds.
Rename approximate_extents() to approximate_clip_extents() so that it is
consistent with the fill and stroke variants and clearer under what
circumstances you may wish to use it.
Use '(void)expr;' instead of 'if (expr) ;' to avoid getting the warning.
'if (expr) {}' is an option, however '(void)expr;' seems like a more common
idiom and getting warnings for __attribute__((warn_unsed_result)) functions is
probably prefered.
PDF requires font names of subsetted fonts to be preprended with
"XXXXXX+" where XXXXXX is a sequence of 6 uppercase letters unique the
font and the set of glyphs in the subset.
Performing the unicode to index is quite expensive, the
FcFreeTypeCharIndex() taking over 12% in the cairo-perf text benchmarks.
By adding a simple cache of translated unicode indices, we save around 25%
of the lookups during benchmarks, with a relative reduction in runtime.
RTLD_DEFAULT is a gnu-ism (at least according to the manpage on my linux
system) so declare _GNU_SOURCE before including dlfcn.h and failing that
provide our own definition.
Profiling a silly video renderer that called set-source; rectangle; fill;
for each pixel, we can shave 5% off the cairo overhead by introducing an
early return if we attempt to reset the current colour.
With Behdad's analytical analysis of the spline bbox, tolerance is now
redundant for the path extents and the approximate bounds, so remove it
from the functions parameters.
The way this works is very simple: Once for X, and once for Y, it
takes the derivative of the bezier equation, equals it to zero and
solves to find the extreme points, and if the extreme points are
interesting, adds them to the bounder.
Not the fastest algorithm out there, but my estimate is that if
_de_casteljau() ends up breaking a stroke in at least 10 pieces,
then the new bounder is faster. Would be good to see some real
perf data.
Joonas spotted that the breakage with the curve bounds was the result of
initialising the spline using the original move to point and not the
current point.
Fixes: Bug 19256 Gnome Foot in gnome-games rendered incorrectly
(https://bugs.freedesktop.org/show_bug.cgi?id=19256)
