[cairo] Re: fix pixel offsets in rotated image sources
bertram.felgenhauer at googlemail.com
Fri Sep 16 15:27:36 PDT 2005
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:
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
> 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
> > 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
> > 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.
More information about the cairo