[cairo] Re: fix pixel offsets in rotated image sources

[Bertram Felgenhauer]

On 9/17/05, Bill Spitzak <spitzak at d2.com> wrote:
> > It's right that this works on the matrix level; note, however, that the
> > translation by -.5, -.5 is only correct for bilinear filtering; for
> > 'nearest' filtering you should leave that out, as I tried to explain
> > in my previous mail.
> 
> I would think it works for "nearest" filtering as well. It certainly

It does not. The filters implemented in pixman (and the Xserver, too)
look like this right now for a single pixel:

Nearest:               Bilinear: 
       ^                      ^
       |                      |
      1|----+               1 +
       |    |                /|\
       |    |               / | \
       |    |              /  |  \
       |    |             /   |   \
--+----|----+----      --+----|----+--
 -1    0    1           -1    0    1   

In a way, nearest filtering already samples at the center of the pixel,
because it truncates the coordinates. Bilinear filtering needs an
additional adjustment.

> works for the identity, 90 degree rotations, and integer scales,

I believe you have not tested integer scales >1 with the nearest filter.
If you have, Xrender behaviour actually differs from cairo's pixman in
that point.

> > I wonder how many applications there are that rely on the current
> > behaviour of Xrender like that, i.e. if it's safe to fix that in the
> > Xserver.
> 
> I would suspect this would be a bad idea as it would break software that
> is already compensating for it, such as my software and Cairo.

Cairo does not currently compensate for this behaviour, so it would in fact
be fixed.

> > cairo/pixman uses (IntToxFixed(1)) to get the appropriate value for 1.
> > Note that >>1 is not guaranteed to work for negative integers.
> 
> Unfortunately /2 rounds toward zero, which is equally broken.

Hmm. I'm not sure if it matters on the 1/65536 pixel/source pixel scale
but yes, that's ugly.

> This produces visible artifacts such as 1-pixel shifts as arbitrary
> calculations pass through zero. Shift rounds down always. I don't think
> there are any machines powerful enough to run Cairo that do not do
> signed shifts correctly.

I have no data about that.

Bertram