This test used to be named -truetype, which reflected the type of font used in
the test, in contrast to the -type1 test that uses a Type1 font. However, we
renamed this test to -type3 to emphasize the fact that a TrueType subset is
not emitted for vertical fonts and a Type3 fallback font is generated.
Now things have changed: we try generating a Type1 fallback font which is what
is happening for this test. Moreover, the -typ1 test also is generating a
Type1 fallback font since the Type1 subset font is not useful for vertical
fonts.
This fixes the last problem with vertical fonts in PS/PDF. As such, remove
ft-text-vertical-layout-type1 test from XFAIL and add PS-specific ref image
to pass.
The float version of many math functions were introduced in C99, and were
causing compile failure on systems like OS X. We now define them to their
double variant if __USE_ISOC99 is not defined. We may want to expand it later
to cover non-gcc compilers too, but since this is pdiff only, it's not really
important.
The PS output for ft-text-vertical-layout-type3 looks correct, except for some
antialiasing mismatch. Ading ref image to fix this, and so, remove the test
from XFAIL.
We update the test suite reference images where needed, (pdiff
avoided a few, but most still needed updating). We take advantage
of the need for new reference images to shrink some of the giant
tests to speed them up a bit.
This optimization provides a 2x improvement in linear gradient
generation performance (numbers from an x86 laptop):
image-rgb paint_linear_rgba_source-512 26.13 -> 11.13: 2.35x speedup
█▍
image-rgb paint_linear_rgba_source-256 6.47 -> 2.76: 2.34x speedup
█▍
image-rgba paint_linear_rgb_over-256 6.51 -> 2.86: 2.28x speedup
█▎
image-rgb paint_linear_rgba_over-512 28.62 -> 13.70: 2.09x speedup
█▏
image-rgba fill_linear_rgb_over-256 3.24 -> 1.94: 1.66x speedup
▋
image-rgb stroke_linear_rgba_over-256 5.68 -> 4.10: 1.39x speedup
▍
I've given up on trying to preserve the old code formatting
for compatibility. We're not planning on augmenting the algorithm
itself, just integrating it into cairo. So I don't expect to
make changes that we'll be all that interested in pushing
upstream.
This is a slightly kinder interface that accepts cairo_image_surface_t
pointers rather than pointers to the raw image data and width, height,
stride. This brings us closer to hooking up the pdiff code.
In a manner similar to flattening in advance, we now extract the sub-
surface of interest (when testing with device offsets) before calling
into the buffer_diff functions. This allows these functions to accept
a single stride value once again instead of one for each of the three
images.
The purpose of this test case is to help make
sure that changes to the trapezoid generation or
intersection computation in the tessellator
don't break it.
Some systems cannot handle very long list of arguments. Carl was hitting this
for "make clean". Break it out into several rm calls triggered by the
clean-local target.
The new tessellator contains a regression where stop events
that aren't followed by start events sometimes cause the
trapezoid to the left of an edge to be too high.
There's currently a regression bug in the tessellation code from
switching to the new tessellator. The bug is caused by
confusion in the comparator used to order events when there are
degenerate edges. This test is derived from the zrusin-another
performance test case.
