There you go Joonas, I don't always ignore your suggestions! This is
simple patch to allow the user to disable symbol loops in case the
auto-detection fails on some obscure (perhaps OpenBSD) platform. Or in
case the user really wants to trim a few bytes from a library only used
during tracing!
Project lines that exceed the 16.16 limits onto the XFixedLine, as we know
that top/bottom must fit within the confines of the surface and so will be
less than 16 bits.
Sadly this is a run-on patch that also does:
1. Make FillTiled the default for new GCs.
2. Stores extend mode as opposed to repeat, and thereby cleaning up some
inconsistent code.
3. Remove the special casing for unbounded trapezoids, as it is redundant
with the polygon clipping.
4. Tidy the logic for deciding when to use the core protocol
(_categorize_composite_operation)
Implement cheap calculation of glyph extents to see whether we can discard
the clip region. This is effective around 50% of the time for firefox (and
makes the xtrace so much neater).
Now that we use polygon clipping, output geometry should no longer exceed
the 2^16 limits imposed by pixman. For the image backend, we now use spans
for stroking and for the xlib backend we have to double check the range on
the output trapezoids. In short, cairo should pass this test.
Fill a region using IN and a white source is a frequent reduction of a
complex clip (viz a path that covers the whole operation extents will be
reduced to a single rectangle), and we can simply discard the fill (as it
always has bounded semantics).
If the clip path is a simple box, then for many operations it is entirely
representation by the alteration of extents and so we can skip a few steps
during reconstruction.
Jeff Muizelaar reported a bug from his firefox builds that was causing a
double free during XCloseDisplay, and suggested it was related to
c0e01d9cd. Reviewing the cleanup, suggested that the cause may just be a
pair of missing parenthesis.
If a backend fails in exactly the same way as the image, then we can
safely assume that the failure is systematic and not an error in the
backend, so change the result to XFAIL.
Do not blindly assume that we managed to construct a valid scaled-font
before attempting to dereference the FT_Face. Consider a machine with
no fonts which is substituting twin...
Some environments may be broken beyond our capabilities to detect, or
maybe the user is just insane and doesn't want to build my nice shiny
cairo-trace. Whatever, give them the option to choose:
$ ./configure --disable-trace
A new -f option to cairo-perf reverts to a fast run
mode for quick performance overviews. The number of
milliseconds each iteration of a test is run for can
be overriden using the new CAIRO_PERF_ITERATION_MS
environment variable. The default remains 2000 ms/iter.
Sometimes it's convenient to run the regression or performance tests
against a given target with a given content. Now we accept an optional
content specifier as a suffix .<content> on a target name, where
<content> is rgb or rgba.
This test is annoying enough as it is what with it wedging the
test suite and all. There's no reason why it should DOS the
running box as well by sitting in a loop allocating like mad.
If the XServer claims to support the required Render extension then send
it the operations. However for the cases where we know it does not work,
i.e. the current and previous generations (<=1.6) of Xorg servers, enable
the buggy_pad_reflect fallbacks.
Add a couple of tests to exercise a bug that Joonas spotted that I had
introduced with the clip-reduction scheme - namely that I had
incorrectly removed the clip on unbounded operations.
The win32 backend handles surface sources directly and never calls
_cairo_pattern_acquire_surface() which is the only other possible user of
clone_similar().
Check for native mutex types before hooking into pthread, as this
workarounds broken builds on mingw that confuse us by including the
pthread header file.
FillRectangle is most frequently used to fill an entire imagee with the
background colour, i.e. with just a single, or few, rectangle. Avoid
heap allocation for this common case by allocating enough space for 4
rectangles (vertices+colors) on the stack.
The calls to uniform_random() to get the curve points were in
the function arguments, but argument order evaluation is compiler
implementation dependent.
The image surface code doesn't reliably work on images larger than
32767 in width or height. This patch makes the image surface
constructors fail by returning a surface in the CAIRO_STATUS_INVALID_SIZE
state when given negative or too large dimensions so that client code
gets a prompt and correct error rather than flaky rendering on large
images.
The test runner was extra strict about never letting a test put
the cairo_t into an error state, and never would it check for
the expectedness status of the failure. This patch moves the
check for a test being an XFAIL above the check on the cairo_t's
final status.
Creating an widthxheight solid picture for using with
RenderCompositeTrapezoids defeats the optimization with the xserver that
checks for a solid alpha pattern. The checks it performs are for
CONTENT_ALPHA, Repeat, 1x1 and value == 0xff.
