[cairo] White seams (lines) appearing between objects

[Carl Worth]

On Tue, 15 Jan 2008 09:55:27 +0100, Kristof Van Landschoot wrote:
> Isn't what we're doing in the code sample turning antialiasing off?
> I.e., the call to
>
> cairo_set_antialias(lCairoState,CAIRO_ANTIALIAS_NONE);

Yes, that is turning off antialiasing.

> is what should take care of it, no?  But we still get the white
> line?

Yes, that should take care of it. I think we both made the mistake of
seeing "seams" in the problem description and assuming you were
running into the long-standing problem of seams from shared geometry
and incremental antialiasing.

> And then I don't see how supersampling could solve the issue since
> even from supersampling a fine white line you would still get a
> lighter color than the red or the black on either side of the line,
> wouldn't you?

Right. You've got a totally different problem in your case. Sorry
about that.

If you replace the drawing of the "red"[*] rectangle image with the
following code:

    cairo_rectangle (cr, 799.52, 464.32, 30, 160);
    cairo_set_source_rgb (cr, 1, 0, 0);
    cairo_fill (cr);

Then there is no longer any seam at all.

So something about the non-antialiased sampling of the image is giving
a result that is different than just rendering a rectangle with the
same geometry.

I've attached a complete and minimal test program for exercising the
bug. It sets CAIRO_ANTIALIAS_NONE then draws a red rectangle with
cairo_fill and then paints a black image over that. And the
rectangular region is given a non-integer offset.

The first thing I discovered is that the image was being painted with
the default CAIRO_FILTER_BEST which introduces "softness" like
antialiasing around the borders. Using CAIRO_FILTER_NEAREST instead
avoids these, (which would appear to be what was desired in the
original code sample). So perhaps CAIRO_ANTIALIAS_NONE should imply
CAIRO_FILTER_NEAREST at least as the default for cases where cairo
creates the source pattern implicitly (like cairo_set_source_surface)?

Meanwhile, even with CAIRO_FILTER_NEAREST the bug is still quite
visible. For example, with an offset of 0.6 added to both X and Y the
image is painted one pixel to the right of the filled rectangle. And
with an offset of 0.5 added to both X and Y the image is painted one
pixel above the filled rectangle. So it still looks like there's an
image-sampling offset bug here somewhere.

I think I'll add this test case as a new failure to the test suite.

Kristof, thanks very much for the report, and I apologize that we
misread your example so poorly at first.

-Carl

[*] Incidentally, the image comes out blue on my system. Your
method of initializing the image array contents will not be consistent
across machines of different endian-ness in general, (though in this
case, the pixel values are symmetric so should result in opaque blue
on any system if I'm reading it correctly).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: seam-test.c
Type: application/octet-stream
Size: 1641 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080115/43c3b365/attachment.obj 
-------------- 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/20080115/43c3b365/attachment.pgp