Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
In the spirit of the new big-{little,empty}-{box,triangle} tests, this test
combines various paths. However, these paths are not only filled but also used
for clipping, resulting in 120 different combinations.
No backend currently succeeds the test. The reference image is a gimp-ination of
the image and test-fallback results and thus certainly wrong. Feel free to fix.
Additionally, this makes the xcb backend die with an ugly failed assert.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Another variant on big-little-box, to make sure we trim the extents
before doing the empty unbounded fixup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The wonders one sees when looking at webpages. Who knew people would be
so inventive with clips?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A discussion that we've been having is the use of contours in filling,
and for optimizing for convex contours in particular. A devious mind
quickly generates a shape using a convex "contour" whose hull is larger
than its area. This is due to the self-intersection of the "contour"
which if properly excised causes the contour to be classed as concave.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This exercises the bug
https://bugzilla.mozilla.org/show_bug.cgi?id=668921
which is caused by a failure to tighten the extents after tessellating
the path and the unbounded fixup is skipped as it is believed the path
covers the whole area.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The mime surface is a user-callback surface designed for interfacing
cairo with an opaque data source. For instance, in a web browser, the
incoming page may be laid out and rendered to a recording surface before
all the image data has finished being downloaded. In this circumstance
we need to pass a place holder to cairo and to supply the image data
later upon demand.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Checks that coincident end-points are not converted to joins. It briefly
passed through my mind that was a good thing...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The complexity in this shape is that the stroke is reversed upon
itself and retraces the same path in the opposite direction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we use this a performance benchmark, it behooves us to check that we
are rendering it correctly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A benchmark to test how close we get to reducing paint+clip to an ordinary
fill, and to check correctness.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not sure what the right results are, so refs will come later. The output
looks superficially right, but the *code* is known to be buggy...
(And hopefully this has captured a few of those bugs.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If I've written the tests correctly, these should produce identical
images as the a1 rasterisation tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The test-antialias-* tests perform the same operation with just a
different antialias flag. Sharing the code ensures that they are kept
in sync and permits adding new flags combinations easily.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=14268
This new test (based on show-glyphs-many) checks that the glyphs
advances are respected along both axes.
9c0d761bfc introduced a bug which
regresses this test in quartz.
Thanks to Jeff Muizelaar for the report!
Test case taken from the WebKit test suite, failure originally reported
by Zan Dobersek <zandobersek@gmail.com>. WebKit test is
LayoutTests/canvas/philip/tests/2d.path.rect.selfintersect.html
The interaction between the group and the state API is currently
untested and buggy. This test tries to use them incorrectly and check
that cairo notices the problem and marks the cr object with an error
status.
This was found via cairo-perf-micro which sometimes triggered this bug in its
mask-similar_image-* test.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old radial gradient tests were actually drawing the same gradients
with different operators (OVER/SOURCE) and operations (paint/mask).
It is possible to refactor them to share the gradient construction
code. This makes it easy to change the gradient shape in all of them
to test more interesting combinations.
Instead of testing 16 generic positions we are now testing just 7
cases, which correspond to every possible combination of the relative
size and position of the two circles defining the gradient. In
particular we are now testing a constant radius gradient and gradients
with tangent circles.
mesh-pattern tests a mesh pattern with non-opaque two overlapping
patches.
mesh-pattern-accuracy tests the accuracy of the color computed in each
point of a patch. It can point out defects in rasterizers which rely
on mesh subdivision only use the mesh shape instead of both shape and
color to decide when the tensor-product patches can be approximated
with Gouraud-shaded triangles.
mesh-pattern-conical is an example of how a conical gradient can be
approximated with a mesh pattern.
mesh-pattern-control-points tests a mesh pattern with control points
in non-default position to verify that their position affects the
color as expected.
mesh-pattern-fold tests a mesh pattern with a patch which folds along
both sides.
mesh-pattern-overlap tests a mesh pattern with a patch which folds
along just one side.
mesh-pattern-transformed tests a mesh pattern with non-identity
transform matrix.
