If I've written the tests correctly, these should produce identical
images as the a1 rasterisation tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
ce3806510f changed the format of
Makefile.refs, breaking the check-ref-missing target.
Ignoring any line not containing a .png file fixes check-ref-missing
and makes it more robust.
Generates the lexicographical Makefile.refs based on the *.ref.png and
*.xfail.png checked into git.
This might be nice to automate as a Makefile target. But for now play
safe and do the updates manually.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The test-antialias-* tests perform the same operation with just a
different antialias flag. Sharing the code ensures that they are kept
in sync and permits adding new flags combinations easily.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=14268
The old code considered every even "word" as a key and every odd
"word" as a value when parsing a test log file.
All of the keys end with ':', so restrict with this requirement.
On linux it is impossible to check the missing references because of
argument length constraints:
make: execvp: /bin/bash: Argument list too long
Using a temporary file instead of variable expansion makes it possible
to work around this.
Makefile.refs is now required to be in lexicographical order, which
avoids ordering problems and the risk of duplicated entries (like
clipped-surface.ref.png).
Test targets now explicitly depend on the cairo library and build it
appropriately.
Phony targets depend on inform, so that they print a warning if the
environment is not set up appropriately.
On Win32, the POSIX-compatible unlink function is named "_unlink".
A function named "unlink" exists, but does not have the same behavior
as the POSIX-specified one. This function makes the cairo test suite
behave incorrectly and immediately terminate with the message:
Error: Cannot remove cairo-test-suite.log: No error
51bd27afa1 removed
make-cairo-test-constructors.c but did not update the win32 Makefiles
accordingly.
cairo-test-constructors.c is now generated by a make target which runs
make-cairo-test-constructors.sh.
In commit 532cbcfbc7 'Add unaligned boxes to "operator-source" test', I
removed some reference images from the test suite, but I forgot to also remove
these files from test/Makefile.am. This caused "make dist" to fail.
Thanks to Alexandros Frantzis for noticing this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
These ref images might be wrong. Since the test failed here already before this
change, I took the old ref images and copied the new part from the test output
underneath it. For the backends that I don't have, I deleted the images (sorry).
After this, the "operator-source" test still fails for me on all backends, but
much more prominently so for the image backend. xcb-render-0.0/argb32 gets
compared against a rgb24 ref image, but apparently this was already the case
before(?). The rest are minor differences.
This reveals a bug in the image backend. This was originally reported here:
http://lists.cairographics.org/archives/cairo/2011-March/021827.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
This new test (based on show-glyphs-many) checks that the glyphs
advances are respected along both axes.
9c0d761bfc introduced a bug which
regresses this test in quartz.
Thanks to Jeff Muizelaar for the report!
The ARRAY_LENGTH macro is used by many tests, although sometimes it is
named ARRAY_SIZE. Define it just once in cairo-test.h and reuse it.
In a similar way, MAX() and MIN() are currently defined in some
specific tests, while they could be reused.
warning: cannot optimize possibly infinite loops
gcc does not detect that the "infinite" loops are actually just one or
two iterations, depending on the has_similar value being FALSE or
TRUE. It realizes it if the iteration variable and the iteration stop
value are both enum values.
Test case taken from the WebKit test suite, failure originally reported
by Zan Dobersek <zandobersek@gmail.com>. WebKit test is
LayoutTests/canvas/philip/tests/2d.path.rect.selfintersect.html
This test creates a similar surface using cairo_push_group () and
assumes its size will be w x h. This is not true when testing similar
surfaces with "cairo-test-suite -a", because they are bigger than the
actual ROI, which corresponds to the rectangle (0,0) - (w,h).
Clipping to the ROI guarantees that the surface created by
cairo_push_group () always has the same size.
Fixes surface-pattern-scale-down-extend.
The test was incorrectly translating the "target" of the context
instead of the "group target" (i.e. the current destination).
"cairo-test-suite -a" runs the tests on similar surfaces created using
cairo_push_group (), thus without this change the device-offset did
not affect the real destination surface.
Fixes clip-device-offset.
This test called cairo_save () without restoring again. Normally, this doesn't
cause a problem. However, when cairo-test-suite is called with "-a", it also
executes the tests on a similar surface. This then caused
cairo_pop_group_to_source to be called on a cairo_save state which causes a
CAIRO_STATUS_INVALID_RESTORE since commit 5d95ae924e.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since 9948b5180a, the *-surface-source tests draw a different image (a
translucent region was added). However, the ref images for xlib-surface-source
with cairo-ps weren't updated and thus the test failed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is consistent with the naming of most cairo types/functions
(example: cairo_foo_surface_*).
The substitution in the code has been performed using:
sed -i 's/cairo_pattern_mesh_/cairo_mesh_pattern_/' <files>
d6dc6e8e39 introduced two regressions:
- the compiler warns about _gradient_stops_are_opaque being unused in
cairo-pdf-surface.c
- get-path-extents now checks for the wrong extents, thus it fails
The interaction between the group and the state API is currently
untested and buggy. This test tries to use them incorrectly and check
that cairo notices the problem and marks the cr object with an error
status.
Since 1cc750ed92a936d84b47cac696aaffd226e1c02e pixman won't perform
the compositing if it can't prove that this the computations it has to
perform will fit within the size of the variables it uses.
It looks like in this case it cannot prove that no overflow will
happen unless surface_width <= 30582. Instead of this size (discovered
by bisection), a safer looking 30000 was chosen. It should still
trigger the problems the original test was looking for, because
backends which support 30000xheight surfaces will likely support
32767xheight as well.
