Merge clip-*-unbounded tests and add self-intersections to the paths
that are drawn. This exposes a bug in the unbounded fixup code in quartz.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use two levels of pthread support: a minimal level used to
build cairo itself, and a full level to build threaded apps
which want to use cairo. The minimal level tries to use
pthread stubs from libc if possible, but falls back to the
full level if that's not possible. We use CFLAGS=-D_REENTRANT
LIBS=-lpthread to find a real pthread library since that seems
to work on every unix-like test box we can get our hands on.
halo uses text_path + stroke + (fill | show_text) to generate a "halo"
around the string. This is to try to replicate a bug described by Ian
Britten in the PDF backend where the rendering of the show_text looked
distorted compared to the stroke.
A couple of different shapes that aim to test the tessellation side of
the rasterisers more... And worryingly there does seem to be an
unexpected systematic error.
This test case should be much clearer than half-coverage over what it
purports to actually test. In each pixel, it draws a single geometric
primitive that coverages a known percentage of the pixel and then we
measure how close the rasterisers are to that ideal.
Add some overlapping triangles (coarse enough for them to be resolved
using Cairo's 24.8 fixed point without loss of precision) to exercise
handling of overlapping subpixel geometry.
Test handling of source clipping with an image - principally to check
handling of mime types and zero-copy image snapshotting in the vector
surfaces and ensure that they work with subsurface patterns as well.
Add tests to ensure that modifications to the subsurface via the
original surface are tracked by the subsurface, i.e. that any snapshots
are detached upon modification of the parent as well as modification of
itself and vice versa.
Carefully handle subsurfaces of a recording surface through the analysis
and paginated surfaces so that we can generate a native pattern for the
vector backends, demonstrated by the PostScript backend.
Nothing remarkable, just a lot of bookkeeping to track the wrapped
surface types and to apply the correct offsets when generating the
subsurface pattern.
cu found a bug when using clipping and fills with the image backend, but
it turns out to be the lost sign bug afflicting everything...
To trigger the bug requires evaluating the clip surface prior to using
in with _cairo_clip_combine_with_surface(). Which is taken along a
particular path when using a clip mask with non-pixel geometry on image,
but more easily hit by the fallback code.
Reported-by: <cairouser@yahoo.com>
This should exercise a bug found by Jeff Muizelaar that
cairo-surface-clipper was mistakenly thinking that clip operations on a
second context was a no-op as the topmost clip path matched that of the
previous context.
It was observed that we never actually test the condition that the
gradient is only defined for a portion of its range, i.e. the starting
offset is >0 and the ending offset is <0. By definition the colour
between 0 and start offset is the start color, so check that this
behaviour is followed by all backends.
Another bug identified by Jeff Muizelaar was that the bounds for a
zero-length (i.e. it started and stopped at the same point) were
miscomputed. This test case exercises that bug.
Note: I believe the output is wrong here when padding a zero-length
gradient. On the left it should be red, and on the right it should be
blue.
