When coercing from one image format to another we performed a paint
operation using a temporary context - this is overkill as we can just call
_cairo_surface_paint() directly.
This commit moves the toy-to-real mapping from the scaled font creation
time to font face creation. A toy font face will keep an internal ref
to an implementation face. Then cairo_scaled_font_create() will simply
substitute the implementation face before creating anything.
This also modifies the cairo-ft toy creation in that we now create a
non-resolved pattern and store it in a cairo-ft font-face. We then
do the resolving and unscaled font creation at scaled-font creation
time. This also means that cairo_ft_font_face_create_for_pattern()
now accepts non-resolved patterns too, and does the right thing about
them. As much as that can be called right.
Some testing of toy font creation performance is in order, as is testing
win32 and quartz font backends.
Since git 1.6 the plumbing commands aren't installed in the user's
path by default. This patch fixes cairo-perf-diff to find the
git-sh-setup command from git's lib dir.
(cherry picked from commit 0c0f4862c5)
Otherwise this may leads to an invalid memory access to r.
Fixes: Bug 18588 - XCB backend fails with missing render.
https://bugs.freedesktop.org/show_bug.cgi?id=18588
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 834f1d7b70)
Sascha Steinbiss reported a bug where the PDF backend was reading beyond
the end of the glyph array:
http://lists.cairographics.org/archives/cairo/2008-December/015976.html.
It transpires that in the early glyph culling in the gstate we were
not updating the clusters to skip culled glyphs.
We were using an overly-liberal find that also deleted copied output for
use in CAIRO_REF_DIR if that directory was below test/. So only delete
files below output/ (which should only be used by cairo-test).
The API should preserve the precision across the public interface so that
the user is able to retrieve the co-ordinates that he used to construct
the path. However since we transform the path to a 24.8 fixed-point
internal represent we currently incur a precision-loss - the affects of
which can be seen in the miter-precision test case for example. It is
planned to move to keeping the path as doubles until the backend
explicitly requests the fixed-point coodinates (and some backends, e.g.
pdf, might only ever use the doubles). Then, barring rounding errors
during path transformations, we should be able to return the exact path
the user set (under an identity CTM, of course ;-).
Frequently to push an object onto the stack all we need is to simply
perform the struct copy - so inline it and only call the out-of-line
function if we need to enlarge the stack.
