Since 1cc750ed92a936d84b47cac696aaffd226e1c02e pixman won't perform
the compositing if it can't prove that this the computations it has to
perform will fit within the size of the variables it uses.
It looks like in this case it cannot prove that no overflow will
happen unless surface_width <= 30582. Instead of this size (discovered
by bisection), a safer looking 30000 was chosen. It should still
trigger the problems the original test was looking for, because
backends which support 30000xheight surfaces will likely support
32767xheight as well.
The image surface code doesn't reliably work on images larger than
32767 in width or height. This patch makes the image surface
constructors fail by returning a surface in the CAIRO_STATUS_INVALID_SIZE
state when given negative or too large dimensions so that client code
gets a prompt and correct error rather than flaky rendering on large
images.
Instead of tagging the sources, which is insensitive to changes, track the
known failure modes by recording the current fail as an xfail.png
reference. (We also introduce a new.png to track a fresh error, so that
they are not lost in the noise of the old XFAILs and hopefully do not
cause everyone to fret).
As we have removed the XFAIL tagging we find, surprise surprise, that some
tests are now working -- so review all the reference images (as also some
.ref.png now should be .xfail.png).
Note: I've only checked image,pdf,ps,svg. The test surfaces report some
failures that probably need to addressed in source. I've not correct the
changes for win32 and quartz. Nor fixed up the experimental backends.
This test attempts to trigger failures in those backend clone_similar
methods that have size restrictions on the resulting image. It also
triggers errors in scaling down large image surfaces as the image
backend also fails this test.
