Adrian Johnson proposed a hack that fixed the current test by simply
scaling the dashed stroke by device_transform.xx. Obviously this exposes a
deficiency in the test case. So add an outer loop to iterate over several
common ppi for both x and y and in doing so reveal more ugly artifacts in
the current fallback code.
A complication I realised after pushing 3eb4bc3 was handling larger
sampled areas. Extending the test case revealed that the optimization
was broken for anything but the identity transform (after removing the
translation). Correctness first, leaving the "pixel-exact" solution for
interested reader...
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.
As proof-of-principle, compute a scale factor to avoid overflow when
converting a linear pattern to pixman_fixed_t. Fixes test/huge-pattern,
but the principle should be extended to handle more cases of overflow.
Since CAN_TEST_PS_SURFACE does not currently require spectre, we were
attempting to compile in spectre support for any2ppm even on systems
without libspectre installed. Fix that by adding a separate flag for
CAIRO_HAS_SPECTRE.
From bug 18010 (https://bugs.freedesktop.org/show_bug.cgi?id=18010),
in order to make flockfile() available we need to set _POSIX_C_SOURCE and
according to the man page, the appropriate feature check is
_POSIX_THREAD_SAFE_FUNCTIONS.
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
The use of fine-grained fallbacks requires the native support of the
SOURCE operator applied to an image on the target surface. SVG 1.2
introduces the "comp-op:src" mode fulfilling this criteria - so we can
enable fine-grained fallbacks for 1.2+.
Update test/fine-grained-fallbacks to exercise this pathway in SVG 1.2 -
as SVG natively supported all the current operations within that test.
This reveals yet another librsvg bug in handling SVG 1.2.
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.
There appears to be no simple solution here, as it seems to be a
fundamental flaw in the design of the meta-surface wrt to replaying into
a fallback image. (I may be wrong, but if Carl found no easy solution then
I feel no shame for my own failure ;-)
Within _cairo_xlib_surface_emit_glyphs() there are a number of
complications to do with packing as many glyphs as possible into a
single XRenderCompositeGlyph*() call. Essentially these consist of
choosing the right function and packing for the current glyphs, describing
runs of glyphs and ensuring that we do not exceed the maximum request size
within a single call. So we add to the test case we an attempt to show 64k
2-byte glyphs and an attempt to mix 64k 1-byte and 2-byte glyphs, with the
change-over point chosen to overflow the maximum request size, should
_cairo_xlib_surface_emit_glyphs() naively resize the current request.
Moral of this story is bugs cluster. If we made a mistake, especially in a
complicated bit of code that is interfacing with another library, then we
are likely to make a similar mistake in future. Disabling this test hid a
regression between 1.4 and 1.6.
I swear that when I said that it was a rounding error, I was looking at an
image where the squares were overlapping the lines and had a listing of
all the coordinates used. However, the current output on all the machines
I have to hand is correct so I believe the underlying bug to be fixed.
Update the reference images for the external renderers because (a) GS
exhibits the same bug cairo had and (b) librvsg/PDF do not use NEAREST
when applying surface patterns, so the squares are blurred as a result.
Avoid requiring (an absent!) rgb24 ref image by using an opaque grey
background. Confirm the reference image is identical to the old one
(modulo the background change) using GIMP.
Sigh - finding a crasher in xlib seemed too good to be true. And it was.
The bug is due to the coupling of the XCloseDisplay with the user_data on
the source surface.
This was an externally trigger XCloseDisplay whilst the user had live
surfaces, so I consider this a gross application bug and therefore does
not require graceful handling within cairo-xlib. However, I'm willing to
listen to reason...
Whilst investigating:
Bug 7360 painting huge surfaces fails
https://bugs.freedesktop.org/show_bug.cgi?id=7360
I found a particular combination of operations that cause a crash within
xlib, so I'm committing the test for posterity.
With the reintroduction of Carl Worth's and Owen Taylor's work to expand
pattern extents as necessary to include extra samples due to the filter
radius, we expect filter-bilinear-extents to PASS. This patch series is
important as it factors out our assumptions about filter radius into a
single function and cleans up the code in its wake.
However, since the external PS/PDF renderers do not necessarily use the same
filter as cairo (and currently they only use NEAREST due to lack of
/Interpolate emission in those backends) we can expect differences in test
output. So add the respective reference images to capture current
expectations and to highlight future changes.
Fixes bugs:
Bug 15349 - bad clipping with EXTEND_NONE
[https://bugs.freedesktop.org/show_bug.cgi?id=15349],
Bug 15367 -Improve filtering handling in cairo-pattern.c
[https://bugs.freedesktop.org/show_bug.cgi?id=15367]
This fixes the filter-bilinear-extents test case and the
related bug entry:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
Though there are still differences in the PDF and PostScript
backends, (primarily because we can't capture cairo's filter
modes in those file formats).
First, explicitly set the filter mode to BILINEAR in case the default should
ever change. And then draw a second pattern with extents that in theory
are larger than the source surface in order to test handling of acquiring
out-of-bounds extents.
For this we extend the boilerplate get_image() routines to extract a
single page out of a paginated document and then proceed to manually
check each page of the fallback-resolution test.
(Well that's the theory, in practice SVG doesn't support multiple pages
and so we just generate a new surface for each resolution. But the
infrastructure is in place so that we can automate other tests,
e.g. test/multi-pages.)
A few tests explicitly checked whether the "ps" or "svg" target was
enabled and this broke because of the name change. So fixup, to run
the generic test if either PS or SVG target is enabled as appropriate.
If the operator is unbounded, then its area of effect extends beyond
the definition of the mask by the trapezoids and so we must always perform
the image composition.
Fixes test/operator*.
Previously the rule for clone_similar() was that the returned surface
had exactly the same size as the original, but only the contents within
the region of interest needed to be copied. This caused failures for very
large images in the xlib-backend (see test/large-source).
The obvious solution to allow cloning only the region of interest seemed
to be to simply set the device offset on the cloned surface. However, this
fails as a) nothing respects the device offset on the surface at that
layer in the compositing stack and b) possibly returning references to the
original source surface provides further confusion by mixing in another
source of device offset.
The second method was to add extra out parameters so that the
device offset could be returned separately and, for example, mixed into
the pattern matrix. Not as elegant, a couple of extra warts to the
interface, but it works - one less XFAIL...
Images in PDF are scaled to a unit square. In PS we set the
ImageMatrix to do the same. When the image is painted we scale the
graphics state to paint the image at the right size. In the case of
Type 3 fonts consisting of bitmap images we want to paint the images
at their original size so we scale the graphics state by the image
width and height.
The bug was that we were scaling by the width/height in the glyph
metrics. For non rotated fonts this worked. However for rotated fonts
the width/height of the glyph images may be larger than the
width/height in the glyph metrics. This resulted in a Type 3 font
where the glyph images were scaled slightly smaller than they should
have been.
The problem showed up on OS X because the freetype backend reuses font_face_t's
which kept the reference count high enough for long enough to avoid the problem.
As opposed to 8.61.
I had actually forgotten we had documented this. If I had
remembered I could have put more meaningful messages with
some of my recent updates to ps-specific reference images.
It's sad to have to do this. Back with commit 1a9809baa was the
original fix for device-offset-scale, (right after the test was
added), and it fixed it for all backends, including SVG. The fix
involved combining device_transform and CTM into the pattern matrix.
But then, we added the mask-transformed-image and
mask-transformed-similar tests, and commit 20be3182ef for fixing an
SVG-specific bug with masks. That fix involved subtracting away the
pattern matrix when emitting a mask to adhere to SVG semantics.
Unfortunately, this change also made the device-offset-scale test
start failing. A correct fix would probably subtract away only the CTM
portion and not the devive_transform. However, the
_cairo_svg_surface_mask function sees only a pattern matrix and
doesn't know how to separate it into CTM and device_transform pieces.
So fixing this will probably require a change to the surface-backend
interface. And since we're not willing to do that so close to a major
release, we're adding yet another XFAIL.
Thanks to help from Chris, we fixed the bug that was making this
test fail with the PDF backend. All that was left was differing
treatment of the edges of the image---easy enough to address
with a pdf-specific reference image.
The only difference here is a tie-breaker condition for image-
sampling position. While we care about that when it's under our
control, (pixman rasterization), we don't have precise
requirements for ghostscript's sampling. So we can capture the
current result as a reference.
These two tests currently fail only for the PS backend,
but they've done so since before the last major release.
The final image result we're getting is definitely wrong
in both cases, but we have not yet been able to verify
if this is due to bugs in cairo (generating PostScript)
or in ghostscript (interpreting and rasterzing the
PostScript).
