[Pixman] [PATCH 0/7] Cover scaling patches & request for assistance
ppaalanen at gmail.com
Wed Aug 26 02:36:06 PDT 2015
On Mon, 24 Aug 2015 21:41:59 +0100
Ben Avison <bavison at riscosopen.org> wrote:
> Some back story...
> First there was this patch:
> Back last October, Søren had this to say about it:
> > A concern I have here is that code might access pixels outside the
> > image that have weight 0. Ie., in the bilinear case, some code might
> > attempt to read the pixel at bits[-1] and then multiply it with 0. But
> > we can't assume that bits[-1] is readable.
> > If I remember correctly, the +pixman_fixed_e * 8 stuff was intended to
> > handle this case.
> > I think it would be worthwhile to have a test that uses fence_malloc
> > for the source buffer and the matrix mentioned in the commit. In fact,
> > the fence_malloc() testing could benefit from being extended in
> > various ways:
> > - having fence pages both before and after the image
> > - having fence pages in the 'stride' part of the image
> Towards this goal, the following patches were posted to the list - and they
> seem to have escaped Patchwork's notice:
these three are marked as "Changes requested", so they are on my plate,
waiting to be re-sent.
This one is
> (note that there were a few minor outstanding points on the first three).
> This series relies upon the test program implemented by those patches to
> prove its correctness, so it would be helpful if they could be finished off
> and committed.
Yeah, I'll put those on top of my todo again.
I was sort of waiting for a reply to
and then forgot and wandered off to vacation.
> If you look in detail at the patches in this series, you'll see that there's
> an outstanding change for a single routine - the one and only scanline fetch
> iter in pixman-ssse3.c, which handles bilinear scaled a8r8g8b8 source
> images. This could probably be fixed using either of the two methods I used
> in the other patches, but pixman-fast-path.c is the most elegant. My problem
> is that I don't know SSSE3 (or any other x86 for that matter) so it would
> represent a big learning curve for me for the sake of just this one
> Is anyone able to help out? I've got a load of other scaling-related goodies
> lined up, but it doesn't make much sense to post them while all these
> fundamentals are still outstanding.
> Ben Avison (7):
> Refactor calculation of cover flags
> More accurate FAST_PATH_SAMPLES_COVER_CLIP_NEAREST
> Split FAST_PATH_SAMPLES_COVER_CLIP_BILINEAR flag
> More accurate FAST_PATH_SAMPLES_COVER_CLIP_BILINEAR
> armv7/mips/sse2: Fix bounds violations in bilinear cover scaled fast
> pixman-fast-path: Fix bounds violations in bilinear cover fetcher
> test: Make image size calculation match COVER_CLIP definition again
> pixman/pixman-fast-path.c | 35 +++++++++++++++++--------
> pixman/pixman-inlines.h | 63 ++++++++++++++++++++++++++++++++++++++++++++-
> pixman/pixman-private.h | 1 +
> pixman/pixman-ssse3.c | 2 +-
> pixman/pixman.c | 37 +++++++++++++-------------
> test/affine-bench.c | 11 +++-----
> 6 files changed, 110 insertions(+), 39 deletions(-)
Do I understand that right, that this series supersedes:
Hmm, is that the only one?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the Pixman