[cairo] Failures on PPC in mask-ctm and mask-surface

[Bryce Harrington]

On Tue, Nov 21, 2006 at 03:51:57PM -0800, Carl Worth wrote:
> On Tue, 21 Nov 2006 14:09:39 -0800, Bryce Harrington wrote:
> > There's an odd issue on PPC64 with a couple of the test cases:
> >
> >   http://crucible.osdl.org/runs/3173/test_output/cairo-test/ppc01/test/
> 
> It is an odd issue, yes.
> 
> > For some reason, cairo's svg backend isn't generating the image
> > properly.  I don't see this issue on the other architectures (x86,
> > x86_64, or ia64).
> 
> I know it's not what you want to hear, Bryce, but it looks like cairo
> is working just fine here, and it's librsvg that is having trouble for
> some reason. ;-)
>
> So something is going wrong in the svg2png conversion for only that
> one file of all the files in the test suite, and only on ppc. It's
> probably a bug that should be reported against librsvg but I haven't
> looked any closer yet.

No prob, I don't have time to look into librsvg-specific bugs, just
wanted to make sure it was reported on-list.

> Meanwhile, another way to avoid all these problems would be to do all
> the conversion to png images on a single "known good" machine, (with
> all the "just right" versions of ghostscript, librsvg, etc.) rather
> than having to replicate those on all machines used to test cairo.

I have the functionality in Crucible for running post-processing tools
on the main test driver, so if you guys refactored the image generation
code out into a script that can be run independently of 'make test', I
could hook it up to run separately.

In fact, that would probably cut out 90% of the frustrations I've had
in testing cairo, because it would break the circular dependency in the
test suite (cairo's test suite depends on librsvg, which has cairo as a
dependency.)

It seems invariably the issues have been following this pattern:  

   a) test suite shows breakage
   b) breakage isn't in cairo, but in the post-processing tools
   c) machine must be resync'd in order to get newer tools
   d) installation of newer post-processing tools requires upgrading 
      additional dependencies, and dealing with any new issues they
      bring along
   f) in order to keep all test machines in sync with same dependency
      versions, now repeat from c for all machines

The troublesome aspect is that all of the above ends up just being pure
overhead - typically whatever the issue is, it's already known and
fixed, so the effort generates no real value, and requires significant
from both the tester (steps c-f) and the developer (step b).

What makes librsvg particularly frustrating is that since it depends in
turn on cairo, then as problems are found and fixed in cairo and new
test cases added, the output of these test cases may require a new cairo
present and break if it isn't.  Thus, you end up in the unfortunate
situation where doing the right thing (adding a new test case) could
lead directly to the breakage that puts you back at step (a) above.

> I'm not sure if that would end up being even more trouble to implement
> than its worth or not.

Given the circular nature of the cairo/librsvg/cairo relationship, my
guess is that the overhead is going to be too high for me to afford to
do the svg testing (I've already had to drop testing of svg on
itanium).

Bryce