Destroy the context and the surface even when the test fails.
I ran into this because cairo_debug_reset_static_data() is called between the
tests on the quartz backend (it doesn't fork) and isn't on other backends? This
is perhaps a mistake...
user-font-rescale stored the current font on the context in order to
create a rescaling proxy font. As we failed to take a reference to the
font, it caught us by surprise when the font disappeared as we modified
the context before creating our proxy. Ho hum.
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.
