Declares _cairo_quartz_scaled_font_backend ahead of time and makes it static.
Also, removes the 'static' from the _cairo_quartz_font_backend definition.
When the cairo-test-suite forks CoreFoundation complains with:
"The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
When forked so avoid doing it in the test suite for now. In the future we should investigate
the possibility of a work around.
If a matrix was something like [0 .000001 0, .000001 0 0] the old code would
assume that xx and yy were greater than 0 and turn the nearly degenerate matrix
into an actual degenerate one. This caused things to blow up later on. Now we
check that our nearly rectangular matrices are not nearly degenerate, and let
the nearly degenerate ones fall through to the non-rectangular path.
Note: I'm not sure why NEARLY_ZERO(d) is fabs(d) < 1/65536 instead of some
other value. Hopefully, it's a useful definition.
This problem was found by a test case attached to:
https://bugzilla.mozilla.org/show_bug.cgi?id=467423
Based on feedback from Jeff Muizelaar, there is a case for a very quick
and dirty extents approximation based solely on the curve control points
(for example when computing the clip intersect rectangle of a path) and
by moving the stroke extension into a core function we can clean up the
interface for all users, and centralise the logic of approximating the
stroke extents.
When analysing the stroke extents, we need the original fixed-point
extents so that we do not incur an OBO when we round-to-integer a second
time. We also need a more accurate estimate than simply using the control
points of the curve, so pass in tolerance and decompose until someone
discovers a cheaper algorithm to determine the precise aligned bounding
box of a bezier curve.
Bah, the compiler failed to do its IPA correctly and wrongly complained
about potential use of uninitialised out-params guarded by the return
value. Silence them!
If we are dithering on the Xlib backend we can not simply repaint the
surface used for a solid pattern and must recreate it from scratch.
However, for ordinary XRender usage we do not want to have to pay that
price - so query the backend to see if we can reuse the surface.
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.
