[cairo] Pixman centre pixel sampling in unantialiased mode.

[Soeren Sandmann]

M Joonas Pihlaja <jpihlaja at cc.helsinki.fi> writes:

> A follow-up to a minor point on the pixman unantialised rasterisation 
> brought up on #cairo:
> 
> The pixman rasteriser treats edges hitting exactly the sample point at 
> the pixel centre as being outside for top/left and inside for 
> bottom/right edges.  This can be seen from the attached test case.  
> The same issue occurs in the antialiased case, but there the issue is 
> much less noticeable.
> 
> I'm also attaching a small patch against pixman to change it to 
> consider top/left inside and bot/right outside, but I haven't really 
> tested it at all apart from this particular case.  Seems to work. :)

There are some fixes for trap rasterization here:

   http://cgit.freedesktop.org/~sandmann/pixman/log/?h=trap-fixes

The first commit there is a fix for the sampling grid being very
slightly skewed towards the bottom of the pixels.

Because pixman uses fix point coordinates, the space between sampling
points cannot be completely uniform. With a 16 bit coordinate space,
there are 65536 subpixels available and we need to position 15
sampling rows, which means there are two different-sized steps between
them, a "small" step and a "big" step. The first sampling row was
positioned a distance away from the top of the pixel that was half the
small step, but to get the same distance between top-of-pixel to first
row and last row to bottom-of-pixel, this distance needs to be half
the *big* step instead. There is some math in the commit message.

The two other patches are based on your patch, but split into X and Y
directions, and the computation is done in a way that I find easier to
follow. 

A consequence of changing the rounding is that on an a1 surface, this:

        cairo_move_to (cr, 1, 1);
        cairo_line_to (cr, 50, 1);
        cairo_stroke (cr);

will now cause the 0th row of pixels to be illuminated, where before
it would illuminate the 1st row. This is correct behavior according to
how cairo interpretes coordinates, but it may be surprising and of
course it breaks the test suite.

Reviews appreciated, as are comments on whether changing the rounding
rules to be more consistent is worth changing the tests and
potentially surprising users.


Thanks,
Soren