On Thu, 03 Sep 2015 17:14:05 +0100, Siarhei Siamashka
<[email protected]> wrote:
On Thu, 03 Sep 2015 13:59:07 +0100 "Ben Avison" <[email protected]> wrote:
Previously, the flag definition was overly cautious, resulting in some
cases which could have been handled by cover paths instead being sent
to repeat paths. I first encountered this myself with
lowlevel-blt-bench, which routinely used repeat paths for its bilinear
tests
Oh, this was actually intended. The bilinear scaling benchmark in
the lowlevel-blt-bench program tries to stress the use case, where
we are fetching pixels from the outside of the source image a little
bit. The reason is that this is quite typical for bilinear scaling
and that's how it is designed to work.
If this whole ordeal with the new COVER flag interpretation was just
a way to make it run fast in lowlevel-blt-bench, then this new
interpretation may not make much real practical sense.
That was just where it started... I should maybe explain that I
encountered it when I was writing bilinear fetchers for ARMv6, which (at
the time (*)) only handled the COVER case. This meant that
lowlevel-blt-bench was useless to me as it stood, because my COVER
fetchers were never selected, and it was important to me because I rely
on it to be able to compare different implementations (for example to
select the best prefetch distance). I was worried there might be
objections to changing lowlevel-blt-bench, and I also knew that I
followed different code paths for different scale factors (which are
fixed in lowlevel-blt-bench), many of which were so extreme that the
L1/L2/M/HT/VT/RT/R tests of lowlevel-blt-bench no longer made sense - so
that's how I came to write affine-bench.
But while writing affine-bench, it became apparent that it's really
complicated from a high level caller's point of view to construct a
transformation matrix that's guaranteed to hit a COVER path - and it
requires knowledge of details of the internal implementation of the guts
of Pixman, even after you deal with the obsolete 8*pixman_fixed_e
adjustment. This seemed wrong to me; I can imagine applications might
well want to use Pixman to scale between pixel centres rather than pixel
edges, and to expect such an application to know whether to exclude the
left pixel, or the right pixel, or both, or neither, and the same in the
vertical direction (for which the rules were often different) in order to
get the best performance is surely unreasonable.
Ben
(*) Actually, I've been revisiting this recently, and for various reasons
I've added repeat support to these fetchers. But now I'm getting a long
way ahead of myself...
_______________________________________________
Pixman mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pixman
