This test case should be much clearer than half-coverage over what it
purports to actually test. In each pixel, it draws a single geometric
primitive that coverages a known percentage of the pixel and then we
measure how close the rasterisers are to that ideal.
Add tests for degeneratate linear gradients (with start point equal
to the end point), degenerate radial gradients (start radius and end
radius equal to zero, same start and end circle) and gradients (both
linear and radial) with just a single stop.
Test handling of source clipping with an image - principally to check
handling of mime types and zero-copy image snapshotting in the vector
surfaces and ensure that they work with subsurface patterns as well.
Add tests to ensure that modifications to the subsurface via the
original surface are tracked by the subsurface, i.e. that any snapshots
are detached upon modification of the parent as well as modification of
itself and vice versa.
Carefully handle subsurfaces of a recording surface through the analysis
and paginated surfaces so that we can generate a native pattern for the
vector backends, demonstrated by the PostScript backend.
Nothing remarkable, just a lot of bookkeeping to track the wrapped
surface types and to apply the correct offsets when generating the
subsurface pattern.
cu found a bug when using clipping and fills with the image backend, but
it turns out to be the lost sign bug afflicting everything...
To trigger the bug requires evaluating the clip surface prior to using
in with _cairo_clip_combine_with_surface(). Which is taken along a
particular path when using a clip mask with non-pixel geometry on image,
but more easily hit by the fallback code.
Reported-by: <cairouser@yahoo.com>
This should exercise a bug found by Jeff Muizelaar that
cairo-surface-clipper was mistakenly thinking that clip operations on a
second context was a no-op as the topmost clip path matched that of the
previous context.
Franz Schmid reported a regression in 1.9.6 when downscaling
and using EXTEND_REPEAT for an image surface pattern. This
patch adds such tests for every extend mode.
The clip-group-shapes-* tests check that it doesn't
matter whether the clip path is set before or after
pushing a group using specific types of clip paths
(aligned/unaligned rectangles and general paths.)
It was observed that we never actually test the condition that the
gradient is only defined for a portion of its range, i.e. the starting
offset is >0 and the ending offset is <0. By definition the colour
between 0 and start offset is the start color, so check that this
behaviour is followed by all backends.
Another bug identified by Jeff Muizelaar was that the bounds for a
zero-length (i.e. it started and stopped at the same point) were
miscomputed. This test case exercises that bug.
Note: I believe the output is wrong here when padding a zero-length
gradient. On the left it should be red, and on the right it should be
blue.
Jeff Muizelaar found a bug in _cairo_clip_init_copy() which was not
correctly propagating the all-clipped status when an empty clip was
saved in the gstate. This test case exercises that bug.
Having added a specialised scan converter on the premise that it should
be better at handling rounded rectangles, ensure that they are indeed
rendered correctly.
A subsurface is a region of another surface that may be used either to
restrict the writable area of a context or the readable extents of a
source. Whilst writing, access to the exterior of the subsurface is
prevented via clipping and when used as a source reads from the exterior
of the subsurface are governed via the extend mechanism of the pattern.
This test does various operations with a clear source surface with
various content types.
The idea is to make sure optimizations done when surface->is_clear ==
TRUE only happen in the proper cases.
Jeff reported a regression found by Mozilla whereby a uniform gradient
was not being premultiplied on conversion to a solid pattern.
https://bugzilla.mozilla.org/show_bug.cgi?id=539165
[Bug 539165] gradients with a single stop do not have their color
multiplied by the alpha.
Whilst investigating:
Bug 31788: SVG <line> with y1 == y2 and both with fractional
part don't render
https://bugs.webkit.org/show_bug.cgi?id=31788
I found that it can be reduced to a no-op clip following a no-op stroke
or fill. These conditions are exercised here and are shown to be a bug
introduced in the 1.9.x development series.
Compositing of alpha-only sources is not throughly tested and
as a consequence the misbehaviour of some backends is not
shown by the test suite.
[ickle: Added XFAILs for pdf, ps, svg.]
This test fills a slightly rotated surface slightly above the 0 line.
This hits some corner cases in the XRenderComposite path.
I discovered these issues while playing with video rendering onto the
canvas in HTML5 (both Webkit and Mozilla have this problem).
I used CAIRO_ANTIALIAS_NONE and a single-color source in the test to get
rid of aliasing issues in the output images. This makes some issues
slightly less visible, but still fails for all of them. If you want to
get a clearer view, disable it and use romedalen.png instead - it has
the same size as the red surface.
(At least) 3 bugs are at work here:
- if _line_exceeds_16_16() triggers for the reference point, the
source surface will be misaligned.
- the intel driver seems to have an off-by-one bug on my i945 when
positioning the source surface, causing black seams at the top
(not visible in the test unless using romedalen.png) and on the left
of the image.
- My Xvfb fails completely in picture up/download in the xlib-fallback
path.
Hunting for a known bug in the xlib backend where it invalidly converts
an argb32 source to rgb24. However, this does not appear to be that bug,
but still a useful exercise nevertheless.
