[Pixman] [PATCH] test: Add cover-test

[Ben Avison]

On Wed, 02 Sep 2015 12:56:40 +0100, Pekka Paalanen <ppaalanen at 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.

If you look at the following ASCII art diagrams, the vertical axis is the
contribution from source pixel 0 (+) and source pixel 1 (x). Where these
coincide, I have used a *. Each column represents an increment of 0.125
(you'll have to read the labels on the horizontal axis vertically). Upper
diagram is nearest, lower diagram is bilinear.

            ++++++++xxxxxxxx



   *********xxxxxxxx++++++++********

   -   -       +   +   +   +   +   +
   1   0   0   0   1   1   2   2   3
   .   .   .   .   .   .   .   .   .
   0   5   0   5   0   5   0   5   0

               +       x
             +   +   x   x
           +       *       x
         +       x   +       x
   *****xxxxxxxx       ++++++++*****

See how the bilinear diagram is already symmetrical; no rounding is
needed of coordinates on the horizontal axis.

Of course, coordinates actually have 13 more bits of granularity than
this, but the same patterns hold.

>> > - Looks like it processes the whole stride, not width * bytespp,
>> >   which means this is going to explode on fenced images in the
>> >   padding, right?
>>
>> Yes, looks like it is. Good spot. That probably does belong in a
>> separate patch; are you volunteering?
>
> I should, shouldn't I? :-)
> I'll do 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.

Ben