Someone apparently forgot to actually add the reference image. And also
forgot to add the test to meson. Sigh.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For me, with this fix, the base image test cases now pass 100%, when
running:
make test TARGETS=image FORMAT=rgba
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
The discrepancies in these tests appear to all be font rendering /
antialiasing, probably due to algorithmic changes in Pixman.
Some of these reference images were updated in Federico's recent patch,
so the fact that they differ on my system may indicate there may be some
system dependencies beyond just pixman, that can cause test result
variation from person to person. Ideally, these would be isolated and
the tests modified to not have such dependencies.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
[In testing, I was able to reproduce Federico's results for most, but
not all, of the test images. There might be some additional
platform-specific discrepancies that need ironed out, but this is a
solid step forward in any case.
Results for a quick run against just the image backend on my system:
--bryce]
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Bryce Harrington <bryce@bryceharrington.org>
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
I don't see how the old reference file could have been generated.
Things I tried:
* Using an old pixman (but it seems that the relevant code for Adobe
extended blend modes has not changed?)
* Using the Cairo version where the test was first introduced.
* Changing the alpha value from .5 to something else.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Tested-by: Bryce Harrington <bryce@bryceharrington.org>
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
I already did the same thing in commit 3e22a8580a. That commit added
a GENERATE_REFERENCE mode that does not use threads and used that for
generating the reference image.
However, the above commit falls into the range between commits
fb57ea13e0 and 3d94269bd4. The later commit reverts the earlier one,
which changed the way that image downscaling works / is used.
This means that the reference image that were generated back then were
broken. Thus, regenerating the images is the right thing to do.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
The PS output from this test is > 100MB due to the duplicated images.
Using CAIRO_MIME_TYPE_UNIQUE_ID reduces the PS output to 650k, runs
considerably faster, and now produces correct output.
This completes the full set of PDF/PS image filters allowing image
data to be passed though without decompressing then recompresssing in
a less efficient format.
The difficulty with CCITT_FAX is it needs some decoding parameters
that are not stored inside the image data. This is achieved by using
an additional mime type CCITT_FAX_PARAMS that contains the params in
key=value format.
The index 0 is a legitimate index used for character codes that do not
correspond to any glyph in the font. Instead, the API reserves 0xFFFF
(kCGFontIndexInvalid) as the invalid index and defines 0xFFFE
(kCGFontIndexMax = kCGGlyphMax) as the maximum legal index.
Fixes text-glyph-range.
Unicode characters in the Supplementary Multilingual Plane are encoded
as surrogate pairs in UTF-16. This test tries to verify that backends
do not perform UCS4 to UTF-16 conversion by truncation.
Test case for bug 89232 - painting a recording surface to a
pdf/ps surface omits objects on the recording surface with negative
coordinates even though the pattern matrix has transformed the objects
to within the page extents.
The image surface also fails when the recording surface is bounded.
Commit 4e3ef57bc8 added
coverage-intersecting-triangles with an incorrect reference and
generator. The test checks the rasterization of two overlapping
triangles in the following position:
. .
|\ /|
| X |
|/ \|
.---.
Since the triangles have both vertical and horizontal sides of size
x/WIDTH, the expected coverage is 3/4 (75%) of (x/WIDTH)^2. The
original code, instead, was checking for a coverage of 0.75*x/WIDTH,
as if one of the sides was always 1 unit long.
The image and xlib backends still suffer from some jitter, caused by
the approximation of the actual coverage by means of sampling. For
this reason their references are still considered XFAIL, even though
their result now looks mostly consistent with the expected reference.
These two images are mis-rendered (clearly evident from visual
inspection). By removing them, the test will fall back to the more
general format-specific images, huge-radial.argb32.ref.png and
huge-radial.rgb24.ref.png.
Note that the huge-radial.pdf tests still fail to pass, but the pdiff
looks more sensible.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66218
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
The pixman downscaling "95" tests attempt to rescale a 96x96 pixmap to
95x95. Ideally the borders between color areas should be sharp, but for
this use case we allow for 1 pixel of blur between the areas as
acceptable. The choice of what color to use for this blurred region is
not important, and in fact varies from backend to backend.
The old reference images were generated by Krzysztof Kosiński's
downscaling algorithm. These new images are against the algorithms
written by Bill Spitzak.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
When investing the symmetry of the raterisation, we want to have a
simple replay of all of the original geometry through a the flipped
recording surface. This reduces the worry about artifacts from the
clipped rendering.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(And include a git add missed from commit
ccd48b3464
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 30 14:06:21 2014 +0100
test: Remove more duplicated reference images
but were mostly invalidated by the rasteriser changes anyway).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to check the behaviour of the analytic rasteriser inside tor,
let's compare it against a very simple rasteriser that uses a rectiliner
256x256 sample grid.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When updating the quorem between cells, we would lose the overflow
increment as it was only applied locally and not preserved by updating
the quorem.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal is to preserve the precision in the gradients of the edges and
only apply the projection into the final cell location. We also include
the half-subrow offset as spotted by Massimo.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84396
Testcase: coverage-rhombus
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have both a argb32 and rgb24 reference image that are identical,
we can replace them with a plain reference image. I also prefer to have
argb32/rgb24 versions of the reference images if rgb24 differs from the
plain reference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Massimo noticed that the record/record-flip were not being rasterised as
identical mirror images due to a half-subpixel offset in the tor scan
converter. This test attempts to reproduce this error by rendering a
rhombus around the origin of each cell (that is it generates 4 mirror
images of a triangle in the 4 different orientations0. The expectation
is that each pixel in the group is lit identically as the coverage is
identical.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84396
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These reference images are generated by the new GENERATE_REFERENCE mode that the
previous commit introduced.
I have no idea what the "base" images. From my reading of the code in
boilerplate/, these images will be used by the test-XXX targets. However, these
seem to generate the same result than e.g. the image backend. Thus, I deleted
these files.
There is still pthread-same-source.quartz.xfail.png. This file was created in
commit b6e16b8d and touched in commit 5a1e590b1. No idea if this is still valid
and since I don't have a Mac, I won't touch it.
The test is still broken on the following backends (out of the backends I have
compiled in). This mostly seems to be differences in image scaling, but I
couldn't figure out an easy way to tell the test suite that the new results are
correct.
test-paginated, ps2, ps3, xcb, xcb-window, xcb-window&, xcb-fallback, xlib,
xlib-window, xlib-fallback, recording
Signed-off-by: Uli Schlachter <psychon@znc.in>
Add test case for https://bugs.freedesktop.org/show_bug.cgi?id=68382
Something has regressed in the recording surface. All the recording
surface based backends lose the alpha from the paint_With_alpha.
The _cairo_color_double_to_short() function converts a double
precision floating point value in the range of [0.0, 1.0] to a
uint16_t integer by dividing the [0.0, 1.0] range into 65536
equal-sized intervals and then associating each interval with an
integer.
Under the assumption that an integer i corresponds to the real value i
/ 65535.0 this algorithm introduces more error than necessary as can
be seen from the following picture showing the analogous
transformation for two-bit integers:
+-----------+-----------+-----------+-----------+
0b00 | 0b01 | 0b10 | 0b11
+-----------+-----------+-----------+-----------+
which shows that some floating point values are not converted to the
integer that would minimize the error in value that that integer
corresponds to.
Instead, this patch uses standard rounding, which makes the diagram
look like this:
+-------+---------------+---------------+-------+
0b00 | 0b01 | 0b10 | 0b11
+-------+---------------+---------------+-------+
It's clear that if the values corresponding to the given integers are
fixed, then it's not possible to decrease the resulting error by
moving any of the interval boundaries.
See this thread for more information:
http://lists.freedesktop.org/archives/cairo/2013-October/024691.html
Reference images updated:
pthread-similar.ref.png
record-paint-alpha.ref.png
record90-paint-alpha.argb32.ref
record90-paint-alpha.rgb24.ref.png
xcb-huge-image-shm.ref.png
xcb-huge-subimage.ref.png
All of these have only one-step differences to the old images.
Also update the image.arg32 reference images, since for now we're just
accepting pixman's output as truth. This fixes up several tests:
was is
Tests run: 420 420
Passed: 224 261
Failed: 195 159
Expected Failed: 0 0
Error: 0 0
Crashed: 0 0
Untested: 0 0
Total: 420 420
Thanks to psychon for finding the code error in the test.
