The Laplacian pyramid can only work on images larger than 3x3 due to the
size of its convolution kernel. So if the image is too small return an
error (-1) before attempting to construction the pyramid.
Andrew Jorgensen spotted that make dist was missing a few headers needed
for compilation and running make distcheck had spurious failures. Add
the missing files to the distribution and a silly one-liner to check for
missing reference images.
As we now generate empty paths, we must be able to handle empty paths
in the user facing API. cairo_append_path() has an explicit check, and
raises an error, for a NULL path->data, so we need to check the
path->num_data first for empty paths.
Generate a real empty path structure instead of returning
_cairo_path_nil, if we have been asked to create an empty path.
(Also add a couple of missing _cairo_error()s and an appropriate test
case.)
Spotted by Fred Kiefer.
Moments after pushing the new test case did I realise the issue...
We do not attempt to write out the surface to the user stream until
we perform the cairo_surface_destroy() by which point we have lost
the ability to interrogate the error status. We can avoid this by
explicitly calling cairo_surface_finish() and then checking the
error status - and we see that the error is indeed reported
correctly.
No bug. Nothing to see here. Please move along. (Apart from the
request for the status to be return from cairo_surface_destroy!)
From bug https://bugs.freedesktop.org/show_bug.cgi?id=7049, we find
that the error status from the user supplied write function to
cairo_*_surface_create_for_stream is ignored and not propagated back
to the surface/context - leading to silent data loss. Incorporate
the suggested test case, a write function that simply returns
CAIRO_STATUS_WRITE_ERROR, into create-for-stream.c.
Use the png_struct->error_ptr to propagate the error status from the
user/stdio read and write functions through the png_error() to the
cairo_surface_write_to_png*() and cairo_surface_read_from_png*()
functions. From there the error is returned back to the user either
directly or as the most appropriate error surface.
(Fixes https://bugs.freedesktop.org/show_bug.cgi?id=6909)
This test demonstrates a bug when compositing an rgb24 image over an argb32
image, (the implementation appears to be examining the alpha channel
rather than ignoring it).
These are useful programs, but they don't belong in test/.
They are never used in the test suite at all. Instead, these
should exist in some demo package, or as applications in their
own right.
(The motivation for the removal is that someone just encountered
a build error with one of these. And I'm not interested in debugging
build errors for unused components.)
A pixman bug had kept this from being correct earlier. It
works now as long as pixman includes the following fix:
8ff7213f39edc1b2b8b60d6b0cc5d5f14ca1928d
rasterize traps that extend outside of the image bounds correctly
I've been seeing failures with the PS backend for these tests
for a while. This is in spite of the face that we've had a PS-
specific reference image for each of these tests. I'm not sure
what the difference is between my current system and the
system used to generate the original ps-specific reference
images.
One thing we definitely need to do is to bundle fonts with the
test suite to avoid problems like this. Another is to start
documenting the systems used to generate reference images.
I get very confused with ghostscript versioning, but I can
at least say that "gs --version" reports 8.15.3 here, (though
the package appears to have an 8.56 version).
The following 4 tests recently started drawing with native operations
in the place of image fallbacks, so we need ps-specific reference images
to account for minor rasterization differences: over-above-source,
over-around-source, over-below-source, and trap-clip.
By checking matrices for invalid determinants, we can prevent the
setting and application of invalid matrices.
The trick used here is that NaNs, as specified by IEE754, always
return FALSE in comparisons. Since we know that the square of the
determinant must be positive definite, then if the comparison is
FALSE the computation must have resulted in a NaN.
By dropping the top frame from suppression, the XrmGetFileDatabase
suppressions will also match XrmGetStringDatabase leaks which are
starting to occur.
The following four tests are disabled:
gradient-alpha, linear-gradient, text-pattern, trap-clip
We don't use XFAIL as that would disable all backends, (but
we can still usefully use these tests on backends other than
PDF).
