Test surfaces using similar surfaces with both CONTENT_COLOR and
CONTENT_COLOR_ALPHA, if applicable. This seems justified by the apparent
bugs in the pdf backend when going from an ARGB32 similar surface to
a destination RGB24 surface as well as isolated bugs in the image
backend.
The original goal was to try and trick the test suite into producing
a xlib surface with mismatching Visual/XRenderPictFormat. This succeeds,
although with a little bit of brute force in the xlib backend, but the
search to reproduce a BadMatch error fruitless.
I don't know if we made minor changes to the pdf backend, or
if this was due to a poppler change, (we recently bumped the
poppler required for testing up to 0.8.0), but any way around
it these test results look just as good as the reference images
they are replacing.
This test case does show a bug, and we have lots of ideas on how
to fix the bug, but we want to wait until after the 1.6 release
before we fix it. See:
http://bugs.freedesktop.org/show_bug.cgi?id=15349
It appears the reference image wasn't generated on a gold-standard
machine, (and yes, the gold standard is, *ahem* whatever happens
to match what Carl's machine does---eventually we'll make the test-
based tests less picky about system configuration like this).
make -j check has the unfortunate side-effect of performing the summary
before the TESTS have completed, both hiding in the stream of test
output and making it useless. Forcibly disable the jobserver so that the
summary is always last at the expense of not compiling the tests in parallel.
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).
There were legitimate bugs in the ps and pdf backends for these
tests, (particularly with the row of glyphs), but these bugs
were recently fixed with:
commit d89edde84d
Author: Vladimir Vukicevic <vladimir@pobox.com>
Date: Tue Mar 4 00:15:46 2008 -0800
[meta] always copy glyph array before passing to _cairo_surface_show_glyphs
and we just failed to notice the fix at the time.
Previously we were using the cairo_fixed_t type which meant we've
historically only been using 16 bits of precision for these offsets,
and recently only 8 bits. Meanwhile, all manipulatons of offsets
have been in floating-point anyway, so we might as well store them
that way.
This change also prevents a rendering regression introduced with the
24.8->16.16 change betwen snapshots 1.5.10 and 1.5.12 .
This change affected gradient-rendering details for the clip-operator
and operator-source tests, so the corresponding reference images are
updated here.
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.
This change in reference image was triggered by the following commit
in the pixman library:
commit f2d8a5caa63596739b4dc47c00daaaafd9f522e2
Author: Søren Sandmann <sandmann@redhat.com>
Date: Mon Mar 10 23:41:52 2008 -0400
Add rounding epsilon for NEAREST filter after transformation, not before.
This hasn't appeared in a pixman release yet. So for now, getting
correct results is a matter of "use latest pixman". Soon we'll
have a new pixman release and we'll make cairo depend on that.
