[Pixman] On sampling (Re: Add a new benchmarker targeting affine operations)

[Pekka Paalanen]

On Thu, 23 Apr 2015 17:12:59 +0100
"Ben Avison" <bavison at riscosopen.org> wrote:

> On Thu, 23 Apr 2015 12:46:56 +0100,
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > I'm guessing yes, because you do that in affine-bench, reversed... am I
> > on the right track here?
> 
> Affine-bench only uses integer translation offsets, and it only uses any
> at all to ensure it's only testing the COVER_CLIP case. This means it's
> effectively testing the scale-from-pixel-edges model, and if you aren't
> testing reflection, rotation or anything else that involve negative
> transform coefficients, and you weren't testing bilinear scaling, then
> you could get away with passing src_x and src_y = 0 to bench().
> 
> You may be getting a bit confused by the fact that when calculating xmin
> etc in main() that I unconditionally half a pixel extra space. Normally
> this is only relevant for bilinear scaling, but a source image that
> satisfies COVER_CLIP for bilinear scaling will always satisfy COVER_CLIP
> for nearest scaling too, and I wasn't too concerned with allocating one
> pixel too many here and there.

Ah, didn't realize that indeed.

> > Ok, yeah. Since Weston is working with geometry rather than pixels, I
> > think that works just fine... except for the left or top edge, which
> > like you said for the pixel occupancy rules, would be accounted to an
> > outside pixel. Sounds like should be removing pixman_fixed_e in Weston
> > from the source area left and top or something to hit COVER_CLIP.
> 
> Remember, affine-bench is doing things kind of backwards compared to what
> most use cases would be. It has a fixed size destination buffer and has
> been told to use a particular affine transform, and it's trying to work
> backwards to find out how large a source image it needs to start from to
> be able to achieve this without having to invoke source image repeat.

Yes, that is what I mean by "reversed".

> 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).

Right.


On Thu, 23 Apr 2015 18:13:56 +0100
"Ben Avison" <bavison at riscosopen.org> wrote:

> 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.

Yes, that is a nice example, I would have never thought it like that.
You are starting with the assumption that the user demands scale 0.5,
and then computes the resulting width. The scale is fed directly into
the matrix.

Would it be good to set a rule of thumb, that when you are scaling
images, first compute the final size, and then compute the
transformation paramaters for Pixman, regardless from which one you
start with?

I'm going to bookmark your email, your explanations are so
thorough and with excellent figures that it can be used as a
reference. :-)


Thanks,
pq