[cairo] get-clip-svg-* test failures

[Carl Worth]

On Fri, 29 Sep 2006 11:39:13 -0700, Bryce Harrington wrote:
>
> Starting a few days ago, we've been seeing some new test fails:
>
> get-clip-svg-argb32 [0]: FAIL
> get-clip-svg-argb32 [25]:       FAIL
> get-clip-svg-rgb24 [0]:         FAIL
> get-clip-svg-rgb24 [25]:        FAIL

Yes, this is a new test for a new feature, and the failure is a good
catch on the part of crucible, (crucible is obviously being more
diligent about running the test suite than I am, for example).

The problem is that the test suite assumes that the backend will
always be able to provide the clip as a list of rectangles if the user
passes in a list of rectangles.

But the current implementation of cairo_copy_clip_rectangles doesn't
guarantee that, (failing for a backend such as SVG that
unconditionally does path-based clipping).

So there is a question to answer before knowing the right way to fix
this:

    What guarantee do we want cairo_copy_clip_rectangles to make? Can
    it return CLIP_NOT_REPRESENTABLE arbitrarily?

If so, then we just need to make the get-clip test case less strict
and just declare the test a SUCCESS when it get a NOT_REPRESENTABLE
status value back.

Otherwise, we would need to fix copy_clip_rectangles to try a bit
harder. For example, in the current failing case, we've got a path
representing one or more rectangles, so it wouldn't actually be that
hard to convert that to the form the user wants back.

(The existing code for converting a path to a list of rectangles is a
bit awkward. The code that does the actual clipping first tessellates
and then tries to extract a pixman_region_t from the trapezoid
list. Saner approaches might simply store rectangles as a primitive in
the path data structure, (and perhaps also recognize sequences of
move_to/line_to calls in the path that result in rectangles).

Oh, but there's another huge ambiguity in the current documentation
for cairo_copy_clip_rectangles. Does it guarantee that the rectangles
it returns are non-intersecting? Or does it only guarantee that the
intersection of the rectangles is the same as the clip region, (and if
so, with which fill rule?).

The answer to that question also has some bearing and how this should
be implemented.

> Also, I've noticed a number of 'Failed to open display:' warnings; I
> have xorg installed on the test machines but not actually running.  Does
> the testsuite require X be up?

In order to test cairo's xlib backend, then yes, it needs to be able
to talk to an X server. The "failed to open display" errors explain
the gray UNTESTED xlib column you are getting in your results.

Oh, And those many failed and timing-out attempts to talk to a
non-existent X server are likely slowing down the test runs quite a
bit, (in terms of wall clock time, but shouldn't be using excessive
CPU time). You could explicitly exclude the xlib backend from the
testing with the CAIRO_TEST_TARGET environment variable if you really
wanted, but it's probably better to just let it attempt to test xlib
so that that will just start working for any machines that can find an
X server.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060929/c4ab91a9/attachment.pgp