On Thu, 23 Apr 2015 17:12:59 +0100
Ben Avison bavi...@riscosopen.org wrote:
On Thu, 23 Apr 2015 12:46:56 +0100,
Pekka Paalanen ppaala...@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 bavi...@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
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
