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

[Pekka Paalanen]

On Wed, 15 Apr 2015 17:03:43 +0100
"Ben Avison" <bavison at riscosopen.org> wrote:

> On Wed, 15 Apr 2015 10:39:54 +0100,
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Tue, 14 Apr 2015 19:00:58 +0100
> > "Ben Avison" <bavison at riscosopen.org> wrote:
> >
> >> Assume the reasonable case that you want to plot the whole of
> >> an image of size x,y at a size m,n. You need to set the diagonals of
> >> the transform to
> >>
> >> floor(pixman_fixed_1*(x-1)/(m-1))
> >> floor(pixman_fixed_1*(y-1)/(n-1))
> >> 1
> >>
> >> and then solve for
> >>
> >>     / 0.5 \   / 0.5 \
> >> T . | 0.5 | = | 0.5 |
> >>     \ 1   /   \ 1   /
> >>
> >> to find the translation coefficients that will ensure the top-left
> >> source pixel aligns exactly to the top-left destination pixel.
> >
> > Urgh, I don't think we account for *that* in e.g. Weston's Pixman
> > renderer. I could bet Weston follows the GL convention of defining the
> > extents of an image region to be the boundaries of the image, not the
> > pixel centers which would leave a half pixel margin outside of the
> > region. I mean, Weston works as if you are transforming geometric
> > primitives like triangles, and rasterization happens later, while it
> > still uses pixel centers at .5 coordinates, meaning that a single pixel
> > covers the X-coordinates [0.0, 1.0).
> >
> > Are you saying that this idea doesn't work with Pixman?
> 
> I had a recollection of Pixman's geometric model, but given that there's
> no documentation I felt the need to go back and check the source code, as
> it can be very easy to get this sort of thing subtly wrong:
> 
> Pixman's scaling is such that pixel centres are similarly positioned
> irrespective of whether you're doing nearest-neighbour or bilinear
> scaling.
> 
> For nearest-neighbour scaling, the nth pixel of a source or mask image is
> considered to cover the space (n, n+1]. Yes, that's inclusive at the
> upper end and exclusive at the lower end, not what you might expect (and
> this is the reason for adjustments by pixman_fixed_e in various places).

Aha. Slightly surprising. Is this only internal to Pixman, or does it
show outside too? That is, something that users should take into
account, needed for the "exact alignment" to hit the COVER_CLIP?

I'm guessing yes, because you do that in affine-bench, reversed... am I
on the right track here?

Sorry if I'm a bit slow here.

> For bilinear scaling, the contribution of the nth pixel scales up
> linearly from 0 at n-0.5 to 1 at n+0.5 then back down to 0 at n+1.5, so
> its overall range of influence is (n-0.5, n+1.5).

Ok, that is as I'd expect, I think.

> Since the centre coordinate of each destination pixel is what is fed
> through the transformation matrix, you can see that under the identity
> transform, there is always a 1:1 mapping from a single source pixel to a
> single destination pixel, irrespective of whether you're nominally doing
> nearest or bilinear scaling. This enables Pixman to select unscaled fast
> paths just by examining the transform.

Right.

> If you scale from the outer extents (in other words, use scale factors of
> x/m, y/n rather than (x-1)/(m-1), (y-1)/(n-1), and align the top-left of
> the first source pixel with the top-left of the first destination pixel)
> then that's fine, as long as:
> 
> a) you're using nearest-neighbour scaling
> or
> b) you're using bilinear scaling and a scale factor > 1 (i.e. reduction
>     rather than enlargement)
> 
> otherwise Pixman will decide that it needs to use a small contribution
>  from a single-pixel border just outside the bounds of the source image,
> for which it then needs to start following the repeat-type rules (pad/
> tile/reflect/none).

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.

Well, that's really off-topic; just for my personal education.


Thanks,
pq