Previously we were setting the target tolerance based on the surface
type. But that doesn't work as multiple backends will provide a surface
of type meta. So instead we put the tolerance as a value in the
cairo_test_target data structure.
With this change, some single-pixel errors of 1 in the SVG backend
should now be ignored.
Manually "cherry picked" from bcb7863f00
(the regular cherry-pick command cannot handle the file renames and
indentation changes involved here).
The interface of the various buffer/image_diff functions is improved to
provide the maximum pixel difference in addition to the number of pixels
that differ. This value can then be used to compare against a per-backend
tolerance.
Currently I've set the SVG backend's tolerance to 1 to handle some issues
we're currently seeing of single-bit differences on different systems, (but
we're not exactly sure why yet).
Also I improved the image_diff routines to properly report a status value
on failure rather than the bogus value of -1 for pixels_changed.
Cherry-picked from d1834cca19
(and fixed ever so slightly to actually compile).
Also combine image_diff and image_diff_flattened into a single function
This was manually taken from 9547521885
(It would have been a cherry-pick, but that doesn't yet handle file
renames.)
The previous change was in b62710d4f8
We just forgot to update the reference images at the time so there
have been false failure results in the test suite until now.
(cherry picked from 670b3ce243 commit)
The modification was performed with care to ensure that the bug
is still exercised. Also, reference images are added.
(cherry picked from 5b7a7f39ad commit)
One of these functions was already documented to be doing this, and
the other one should have been. Now the documentation and behavior
for both are consistent, (and the path-data test case verifies this).
(cherry picked from 5f833c134b commit)
The bug shows up when doing cairo_copy_path_flat for a path that has
a curve_to immediately after a close_path. When the curve is flattened
the flattener is using (0,0) as the initial point rather than the proper
close_to point.
This test also serves to ensure a similar bug doesn't crop up when
closing a path that begins with an implicit move_to, (as from cairo_arc).
In that bug the path state may have no last-move-point and the path
is closed to (0,0). This bug is not present currently, but did appear
during the development of a fix for the bug above.
The difference here is that the SVG backend uses a meta-surface for
its similar surface, so there are no rasterization/filtering
artefacts when scaling the source surface.
that combine vertical layout with font_matrix rotation and translation.
Currently Type3 and Type1 font paths both show broken behavior.
The type1 test uses "Nimbus Sans L" as the font.
Don't hardcode Valgrind flags in tests/Makefile.am so that
tests/Makefile doesn't need to be rebuilt to use different flags. Not
everybody is looking for memory leaks.
This is useful to review every once in a while to drop duplicate images that
can be dropped. For example, if there are two identical images one named
some-test-svg-rgb24-ref.png and other some-test-svg-argb32-ref.png, those two
can be replaced with some-test-svg-ref.png.
