We frequently use '-' within the test name or format name and so we
encounter confusion as '-' is also used as the field separator. At times
this has caused a new test to break an old test because the new test would
match one of the old test's target specific reference images. So switch
everything over to use '.' between fields (test name, target, format,
subtest, etc.).
Avoid calling libtool to link every single test case, by building just one
binary from all the sources.
This binary is then given the task of choosing tests to run (based on user
selection and individual test requirement), forking each test into its own
process and accumulating the results.
Behdad wants to include the feature with 1.10, so we enable it as early as
possible in 1.9 dev cycle to generate as much feedback as possible.
The first change is to use "<cairo>" as being a name unlikely to clash
with any real font names.
This reverts commits:
a824d284be,
2922336855,
e0046aaf41,
f534bd549e.
This test relied on the recently-removed ability to select
the internal twin-based font family with a name of "cairo".
Presumably, we'll want to bring this test case back when
some other means of requesting that font face is added.
Test the decomposition of 5 different types of spline curve. Useful test
for future experiments in improving the decomposition algorithm.
Note: the vector targets all need separate reference images due to their
lack of support for cairo_set_tolerance(). Also GS strokes the Bezier
curve differently using offset curves and opposed to transcribing the
outline of a pen.
As identified in bug 15479,
Unpredictable performance of cairo-xlib with non-integer translations of a
source surface pattern
(https://bugs.freedesktop.org/show_bug.cgi?id=15479),
source surfaces with a fractional translation hit slow paths for some
drivers, causing seemingly random performance variations. As a work-around
Owen Taylor proposed that cairo could convert non-integer translations on
NEAREST sources patterns to their integer equivalents.
The messy detail involved here is replicating the rounding mode used by
pixman for the sample offset, but otherwise the conversion is fairly
trivial.
Add a test case to capture the current behaviour when a segment ends on
an off/on dash transition.
Originally filed as bug:
Miter artifacts for dashed strokes
https://bugs.freedesktop.org/show_bug.cgi?id=17973
mitch reported on irc that expose events in the gimp were suffering from
artifacts which he tracked down to a bug with clipping and source
surfaces. This is the cairo test case for that regression.
Are patterns mutable? The image backend is quite happy to write and read
from the same surface, whereas the vector targets create snapshots... This
test case exploits that inconsistency.
Also the interested reader will note that not only does this demonstrate
translational invariance, but a discrepancy with similar surfaces.
Application of a pure-alpha similar source is inconsistently handled
across the backends. The PDF/PS backends allow the rgb channels to bleed
through and the SVG backend mixes in pure white.
Quote Kai-Uwe Behrmann:
"The expected behaviour for masking in Cairo is to set the mask according
to the current active matrix and apply unchanged to a to be masked
surface.
In SVG the mask element is bound to the masked object and thus the local
matrix from that image object applies to the nested mask as well."
This is a test case to exercise applying a mask to an image under
separate transformations.
Original patch by Kai-Uwe Behrmann, altered to run the test against all
backends (where it causes poppler to crash on my machine <evil grin>).
The ability to draw glyphs with different metrics is useful when doing
font substitution with fixed layout like in pdf and I eventually plan on
adding code to poppler to do something similar.
A slight variation on the simple fill-alpha theme is that if Company is
truly seeing a regression where we dither, the error on a constant
background will be small and might be missed by the test suite.
Benjamin Otte reported "who broke rgba fills? they look dithered with
recent git."
This commit is the result of a skim through the test-suite which revealed
no single test responsible for checking the basic operation of
"set_rgba(); fill();".
If the gradient has constant alpha, then we can express it as a flattened
linear gradient. Otherwise, should the opacity vary across the gradient we
need to fallback.
Quick summary of changes:
- Move list of cairo source files out of src/Makefile.am and into
src/Sources.mk,
- Generate files src/Config.mk and src/Config.mk.win32 that choose
the right set of source files and headers based on configured
backends and features. This drastically simplifies building
using other build systems. The src/Makefile.win32 file needs
to be updated to reflect these changes.
- Add README files to various directories,
- Add toplevel HACKING file.
Be explicit about handling cached FAIL images, instead of relying on the
sequences of failed matches as the files are an external resource and we
can not guarantee their individual accessibility.
Note this also changes the filename, so you may want to run:
$ find -name '*-last.*' -print | xargs rm
after this checkout.
Compare the current output against a previous run to determine if there
has been any change since last time, and only run through imagediff if
there has been. For the vector surfaces, we can check the vector output
first and potentially skip the rasterisation. On my machine this reduces
the time for a second run from 6 minutes to 2m30s. As most of the time,
most test output will remain unchanged, so this seems to be a big win. On
unix systems, hard linking is used to reduce the amount of storage space
required - others will see about a three-fold increase in the amount of
disk used. The directory continues to be a stress test for file selectors.
In order to reduce the changes between runs, the current time is no longer
written to the PNG files (justified by that it only exists as a debugging
aid) and the boilerplate tweaks the PS surface so that the creation date
is fixed. To fully realise the benefits here, we need to strip the
creation time from all the reference images...
The biggest problem with using the caches is that different runs of the
test suite can go through different code paths, introducing potential
Heisenbergs. If you suspect that caching is interfering with the test
results, use 'make -C test clean-caches check'.
In order to achieve substantial speed improvements the external conversion
utilities are rewritten as a daemon that communicates with the test suite
over a local socket. This is faster as it avoids the libtool and dynamic
linker overhead for each invocation, the caches persist between tests and
we no longer require a round trip through libpng.
The daemon is started automatically by the test suite and if communication
cannot be established then it falls back to using a pipe to a normal
conversion utility. The daemon will then persist for 60 seconds waiting
for further connections.
Of course any memory leak (stares at poppler) is exacerbated.
Franz Schmid reported on the mailing list,
http://lists.cairographics.org/archives/cairo/2008-April/013912.html,
an issue with drawing a dashed rubber band in Scribus. The problem
appears when segments of the dashed rectangle are outside the image,
with the errant dash connecting the ends of the visible segments.
This bug first was fixed in 40558cb15e,
but then reintroduced in 9cfd82e87b, which
became part of the 1.6.2 quick release.
As penance to make sure I never repeat this same bug again, I offer this
test case which exercises the XSetClipMask(NULL) path and hopefully
simulates some 'typical' usage of cairo by GUI toolkits.
The experience of running the entire test suite under cairo_push_group()
did at least reveal that there was a potential bug in the pdf backend.
This test is just the simplest of drawing operations - simply filling
the similar surface with solid blue, and then blitting that surface to
the destination.
This test exercises code that computes the extents of a surface
pattern with CAIRO_FILTER_BILINEAR, (where the filtering
effectively increases the extents of the pattern).
The original bug was reported by Owen Taylor here:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
PDF has a concept of "soft" masks, for which it is able to construct a
mask out of PDF drawing operations. These tests exercise constructing
various masks using the high level drawing operations.
Interestingly, this test case does demonstrate that cairo-pdf
is fixed, (where without commit f6509933a4 the Y positions
of the glyphs were inverted); however, cairo-ps is failing
with this test, (all the glyphs are ending up on top of each
other).
This reproduces the bug in PS/PDF/Win32-printing where an unsupported
operation that is off the page causes an unsupported operation
assertion in the backend.
