On Thu, 3 Sep 2015 13:53:26 +0300
Pekka Paalanen wrote:
> On Thu, 27 Aug 2015 11:45:22 +0100
> "Ben Avison" wrote:
>
> > On Thu, 27 Aug 2015 03:55:07 +0100, Siarhei Siamashka
> > wrote:
> > >> -/* Expand the source
On Thu, 03 Sep 2015 13:59:07 +0100
"Ben Avison" wrote:
> On Thu, 03 Sep 2015 11:13:25 +0100, Pekka Paalanen
> wrote:
> > Unless, you go and change the implementation meaning of Pixman's cover
> > flags which, reading your other reply, is what you
On Thu, 27 Aug 2015 11:45:22 +0100
"Ben Avison" wrote:
> On Thu, 27 Aug 2015 03:55:07 +0100, Siarhei Siamashka
> wrote:
> >> -/* Expand the source area by a tiny bit so account of different
> >> rounding that
> >> - * may happen
On Wed, 02 Sep 2015 20:15:26 +0100
"Ben Avison" wrote:
> On Wed, 02 Sep 2015 12:56:40 +0100, Pekka Paalanen
> wrote:
> > Right. I looked at fast_bilinear_cover_iter_init() and
> > fast_fetch_bilinear_cover() -> fetch_horizontal(), and yes, that
On Wed, 02 Sep 2015 20:34:56 +0100
"Ben Avison" wrote:
> On Wed, 02 Sep 2015 14:03:01 +0100, Pekka Paalanen
> wrote:
> > I am still a tiny bit struggling with why 31 and not 32, but it does
> > add up.
>
> Maybe the reasoning in the comments in
On Wed, 02 Sep 2015 17:14:07 +0100
"Ben Avison" wrote:
> On Wed, 02 Sep 2015 09:15:24 +0100, Pekka Paalanen
> wrote:
> > Changes in v3:
> >
> > - Do not print progress messages unless VERBOSE environment variable is
> > set. Avoid spamming the
As discussed in
http://lists.freedesktop.org/archives/pixman/2015-August/003905.html
the 8 * pixman_fixed_e adjustment which was applied to the transformed
coordinates is a legacy of rounding errors which used to occur in old
versions of Pixman, but which no longer apply. For any affine
On Wed, 2 Sep 2015 20:35:59 +0100
Ben Avison wrote:
> This test aims to verify both numerical correctness and the honouring of
> array bounds for scaled plots (both nearest-neighbour and bilinear) at or
> close to the boundary conditions for applicability of "cover" type
On Thu, 03 Sep 2015 11:13:25 +0100, Pekka Paalanen wrote:
Unless, you go and change the implementation meaning of Pixman's cover
flags which, reading your other reply, is what you are doing. I'm
finally starting to see it.
Glad the penny has dropped! The issue has been
On Thu, 03 Sep 2015 17:14:05 +0100, Siarhei Siamashka
wrote:
On Thu, 03 Sep 2015 13:59:07 +0100 "Ben Avison" wrote:
Previously, the flag definition was overly cautious, resulting in some
cases which could have been handled by cover paths
This patch affects all functions defined by the macro
FAST_BILINEAR_MAINLOOP_INT, which can be identified by the fact that their
names start with the string "fast_composite_scaled_bilinear". These are
currently found in arm-neon, mips-dspr2 and sse2 implementations.
The inner pixel loop for these
The bilinear cover fetcher was implemented with similar assumptions to
FAST_BILINEAR_MAINLOOP_INT - that for all transformed destination
coordinates, you could divide by 2^16, round down and add 1, and still be
within the source image.
This patch effectively reverses this - dividing by 2^16,
12 matches
Mail list logo