On Wed, 02 Sep 2015 20:15:26 +0100 "Ben Avison" <bavi...@riscosopen.org> wrote:
> On Wed, 02 Sep 2015 12:56:40 +0100, Pekka Paalanen <ppaala...@gmail.com>
> wrote:
> > Right. I looked at fast_bilinear_cover_iter_init() and
> > fast_fetch_bilinear_cover() -> fetch_horizontal(), and yes, that really
> > is how it is implemented. The leftmost pixel is chosen essentially by
> > n = pixman_fixed_to_int(x - pixman_fixed_1 / 2).
> >
> > So, pixman_fixed_1 / 2 -> 0, not -1.
> >
> > The thing that confuses me is that with nearest, x=0 will sample pixel
> > n=-1. However with bilinear, x=0.5 will sample pixels n=0 and n=1, not
> > n=-1 and n=0.
>
> When x=0.5, the numerical output of bilinear scaling only depends upon
> source pixel n=0. The stuff about whether you consider pixel n=+1 or n=-1
> to be involved but with a weighting factor of 0 is incidental to the
> numerical output. With nearest scaling, you don't have the option of
> sitting on the fence so you have to round one way or the other.
Yes, I have no problem with the weight zero.
My point is with the memory accesses. Bilinear fetchers always fetch
two pixels regardless of the coordinate, right? At least they must be
allowed to do that for efficient inner loop implementations, or so I've
understood the current design in Pixman.
Therefore when we are tightening the cover boundaries and relaxing the
conditions when cover is applicable, we must take that memory access
into account, even if the weight is zero. We must know whether all
paths sample on the left or the right the zero-weight pixel, when
sampling the exact center of a pixel.
Indeed, nearest does
n = pixman_fixed_to_int(x - pixman_pixed_e)
and bilinear does
n0 = pixman_fixed_to_int(x - pixman_fixed_1 / 2)
n1 = n0 + 1
Just like you explained, the epsilon offset applies only to nearest,
and that is what I find confusing. That's all. It is like nearest
"rounds" down, while bilinear "rounds" up by sampling n0 + 1 instead of
n0 - 1 when x is exactly half.
Anyway, that should be all settled now.
We just have to remember the "always sample two pixels" when we tighten
the cover boundaries for bilinear, since we must avoid accessing memory
outside of the row.
Unless, you go and change the implementation meaning of Pixman's cover
flags which, reading your other reply, is what you are doing. I'm
finally starting to see it.
> Of course, I've now changed cover-test so it doesn't do randmemset
> straight into fenced images anyway (due to needing to handle systems with
> different memory page sizes) so this is no longer an issue.
D'oh, of course, that's why Oded didn't see a segfault. But he did say
the CRC does not match on PPC64, neither LE nor BE.
Thanks,
pq
pgpyy7N6ZjHlb.pgp
Description: OpenPGP digital signature
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
