[Pixman] [RFC PATCH 0/3] Add fence_image_create_bits() test helper

[Pekka Paalanen]

On Thu, 14 May 2015 00:19:40 +0100
"Ben Avison" <bavison at riscosopen.org> wrote:

> On Fri, 08 May 2015 13:45:34 +0100, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > Ben, I think you know better what the actual tests for "More accurate
> > COVER_CLIP_NEAREST|BILINEAR" should look like. I hope this implements
> > the fence part properly. Would you like to write the out-of-bounds
> > tests or explain me what they should do?
> 
> Without going to a lot more trouble to trap bad accesses at finer than
> page granularity, I think those fences are the best you can do.
> 
> The main aim of the test should be to check that when a scaled plot
> requires source pixels going right up to the edge of the source image
> coordinate space, that it doesn't read beyond the limits. At present,
> this is guaranteed because we fall back from a COVER fetcher to a PAD/
> REPEAT/NONE/REFLECT fetcher instead (or the equivalent categories of fast
> paths) before we get all the way there - although this will only be
> apparent from benchmarking or by interrupting the test in a debugger.
> 
> To prove the validity of the patch in question, we need to be able to
> demonstrate that we can safely continue to use a COVER routine all the
> way to the edge of the source. Or at least, if we have to compromise and
> set a tighter threshold before switching to a more general purpose
> routine, that it is still safe to do so.
> 
> What we need to test:
> * Both nearest-neighbour and bilinear scaling.
> * A range of scale factors, both reduction and enlargement. I remember
>    that I used a variety of routines for difference scales of reduction
>    (1..2x, 2..3x, 3..4x and so on) to avoid having to hold the integer
>    part of the increment in a register, so we need to test up to at least
>    8x reduction.
> * We need to test alignment with both the extreme minimum and extreme
>    maximum source coordinates permitted. Given that the scale factors
>    can't be assumed to be nice numbers, I think we need to test them
>    independently, using the translation offsets in the transformation
>    matrix to ensure they align as desired.
> * Possibly test "near miss" cases as well, though these would probably
>    want to be weighted so that positions at or closer to the limit are
>    checked most.
> * Test both horizontal and vertical axes.
> * We should survey which Porter-Duff operations have scaled fast paths
>    (across all platforms) and make sure we test each of those, plus at
>    least one other which will guarantee that we're exercising the fetchers
>    - XOR is probably safe for this.
> 
> For nearest-neighbour scaling, the acceptable criteria should be:
> * Low end: centre of first output pixel coincides with source coordinate
>    pixman_fixed_e
> * High end: centre of last pixel output coincides with source coordinate
>    pixman_fixed_1*width
> 
> For bilinear scaling:
> * Low end: centre of first output pixel coincides with source coordinate
>    pixman_fixed_1/2 (i.e. centre of first source pixel)
> * High end: I'm slightly torn on this one. You could say
>    pixman_fixed_1*width - pixman_fixed_1/2
>    But it's also true that BILINEAR_INTERPOLATION_BITS comes into play,
>    meaning that some slightly higher coordinates should also be achievable
>    without requiring any input from the out-of-bounds pixel. For
>    BILINEAR_INTERPOLATION_BITS=7, anything up to and including 0x0.01FF
>    higher than this should be indistinguishable. And yes, that does mean
>    that there is a very slight bias because coordinates are truncated by
>    9 bits, rounding towards zero.
> 
> Having had to carefully think through writing the specification above, I
> have some idea how I'd go about writing it - but if you can follow that
> description, feel free to have a go yourself!

Hi Ben,

that is a lot to chew. I see why you wanted to leave this for later. :-)
Thank you for writing the spec down.

I'm currently benchmarking the over_n_8888 and over_n_0565 patches,
both fast and armv6, on the rpi1. I should have results next week, so
I'll take care of that first, and then think what would be best next.
I'm using the same harness as I did the last time we were upstreaming
patches.

Let me know if you start writing the test and I'll tell you if I start
so we don't cross.

I pushed my updated fenced-image patches to
https://git.collabora.com/cgit/user/pq/pixman.git/log/?h=fenced-image-v2
Once I figure out if I need the configure tests, I'll post it again. Or
if we get the test written. If you write the test and want to post it,
feel free to post the whole series.


Thanks,
pq