If we cannot test the xlib backend simply because there is no Display,
just report UNTESTED and do not clutter the output with superfluous
warnings [see the output from the buildbots for an example]. However,
keep the warnings around so that a developer can re-enable them
and so simply move them to a new "lower priority" macro.
As reported in https://bugs.freedesktop.org/show_bug.cgi?id=19283, the
fallback freetype version compare is broken inside the configure script as
the $1-$3 arguments are interpreted as the script is constructed. To avoid
making that awk comparison any more complicated, we import a version compare
from the autoconf archives - such that we have a reusable macro for the
furture.
In order to have locale-independent output of decimal values, we need to
manually transform such numbers into strings. As this is a solved problem
for cairo, we adopt _cairo_output_stream_printf() and in particular the
_cairo_dtostr() routine for our own printf processing.
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.
This interferes with the application being traced. It is not clear from
printf(3) whether "%.f" is locale dependent or not - but until we have a
failure do not break applications unnecessarily!
Handle the case of tracing an application that spawns it own graphical
children but using the autonaming facility within cairo-trace. Currently
the traced process tree would all attempt to write to the same file,
creating a broken trace. This means sacrificing the display of the output
name, but allows use for a wider range of applications.
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)
