[Pixman] [PATCH 5/5] test: Add a new benchmarker targeting affine operations

[Ben Avison]

On Thu, 23 Apr 2015 17:12:59 +0100, I wrote:
> I imagine most of the time, you'll have a source image of fixed size, and
> you'll either have a target destination size (in which case your task is
> to calculate the transform matrix coefficients) or you'll have a target
> scaling factor (in which case your task is to work out the destination
> size that can be achieved without running off the sides of the source
> image).

Just to add to this, an example has come to mind that demonstrates why
higher level software should really know about the pixman_fixed_e offset
for nearest-neighbour scaling in order to make best use of Pixman.

Assume we have a source image that's 101 pixels wide, and we know it has
to be plotted at a scale factor of 50%. How many destination pixels do we
tell Pixman to plot?

In reality, given a transform matrix whose diagonal is (0.5, 0.5, 1),
Pixman is capable out picking out source pixels with index 0, 2, 4, 6 ...
100 - that's 51 pixels - whilst still using a COVER_CLIP fast path. If it
weren't for the pixman_fixed_e offset, it would pick out source pixels 1,
3, 5, 7 ... 99 instead - that's 50 pixels.

Now, if the caller asks for 50 pixels and Pixman uses the offset, then we
get to use the COVER_CLIP fast path, but we've trimmed two pixels off the
right and none off the left.

But if the caller asks for 51 pixels and Pixman doesn't use the offset,
then Pixman realises it needs a value for out-of-bounds pixel index 101
so won't use the COVER_CLIP fast path.

So, for the best combination of image quality and speed, the details of
Pixman's rounding algorithm *can* be significant.

Ben