[cairo] Pixman sampling coordinates (Re: White seams (lines) appearing between objects

[Carl Worth]

On Tue, 15 Jan 2008 19:25:33 +0100, Bertram Felgenhauer wrote:
> May I suggest that it's the rendering of the rectangle that's odd here,
> and not the sampling of the image?

Thanks for the clarification.

> OFFSET=0.5 is a boundary case, it's hard to get this correct.

They should still be consistent in this case. So I think both the
rendering of the geometry (trapezoid sampling) and the rendering of
the image (surface sampling) both have bugs.

I've just pushed two new tests (a1-traps-sample and a1-image-sample)
that both fail which you can read here:

http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=50d0767c8bf4c738b86e10be09d5c4fd7e14a05f

In both cases I'm trying to draw a grid of 100 single-pixel squares
each slightly offset by a different amount on the sub-pixel grid so
that you can watch and see the point where the offset changes which
relative pixel sample position is considered "inside" the square.

What I believe I'd like to see in each case is the following
image.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a1-traps-sample-ref.png
Type: image/png
Size: 148 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080118/8c309f02/attachment.png 
-------------- next part --------------

This corresponds to sampling nominally at half-integer positions, but
with an infinitesimal adjustment of the sampling point toward the
origin. That is, if a trapezoid left or top edge lies exactly on a
sample point, that sample is considered outside, but if a trapezoid
right or bottom edge lies exactly on a sample point, that sample is
considered inside.

What I'm instead getting in the case of trapezoid rendering is the
following:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a1-traps-sample-image-argb32-out.png
Type: image/png
Size: 147 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080118/8c309f02/attachment-0001.png 
-------------- next part --------------

This is obviously wrong as there is a visible break along the Y axis (at
the desired position), but none at all along the X axis. This
corresponds to a sample position that is a full half-pixel too far to
the right. I've attached a patch for pixman below that does fix this
test case. But it restricts its fixup to the A1 case, and Keith points
out that there may be a similar problem with the positions of the A8
sample points. So this is really just a simple hack to show *where* a
real fix belongs, but is likely not that real fix yet.

Meanwhile, here's the result I'm getting in the case of image
rendering:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a1-image-sample-image-argb32-out.png
Type: image/png
Size: 146 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080118/8c309f02/attachment-0002.png 
-------------- next part --------------

Here the break is visible on both axes, which is good, but it's below
and to the right of where I expected it. I believe this corresponds to
a sample position at the half-integer locations but with the "tie
breaking" happening in the opposite direction compared to what I
described above.

I don't know that we really care all that much which direction the tie
breaking goes in any absolute sense. But as the original bug report
that started this thread shows, it is important that all different
kinds of rendering, (trapezoid rasterization and image sampling), have
consistent behavior. So one or the other of trapezoid or image
tie-breaking rules will have to change before we can get consistent
results. I have not yet worked on tracking down where in pixman an
adjustment would have to be made to change the image-sampling
position, (presumably fbFetchPixel or whatever it's named).

Anyway, that's where things stand for now. And the new tests in the
cairo test suite should be useful for anyone wanting to look at this
more closely.

-Carl

PS. The recent tests are explicitly disabled for the vector backends,
(with the blacklist in cairo-test.c), but before I did that I noticed
a visible difference between the PDF and SVG results for one of these
tests, (image I think). And it looked like PDF is likely the wrong
one. So someone might want to look into what's happening there and
perhaps write a new test specifically to exercise that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pixman-trapezoid-sample-position.patch
Type: application/octet-stream
Size: 476 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080118/8c309f02/attachment.obj 
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080118/8c309f02/attachment.pgp