[Pixman] Benchmarked: [PATCH 1/4] Change conditions for setting FAST_PATH_SAMPLES_COVER_CLIP flags

[Ben Avison]

On Fri, 18 Sep 2015 19:35:02 +0100, Bill Spitzak <spitzak at gmail.com> wrote:

> On Wed, Sep 16, 2015 at 7:30 AM, Ben Avison <bavison at riscosopen.org> wrote:
>
>> Just by thinking things through, I realised that we would regularly
>> fail to hit COVER paths if Pixman's caller set the scale factors such
>> that the centre of the outermost destination pixels aligned with the
>> centre of the outermost source pixels. There has been some argument
>> about whether this is representative of how Pixman should be used. I
>> happen to think this is a perfectly reasonable thing to expect Pixman
>> to support, but there are other models you can follow, notably setting
>> the scale factors such that the outer edges of the outermost
>> destination pixels align to the outer edges of the outermost source
>> pixels. If the Cairo traces are using this latter model, then it's
>> understandable if you aren't hitting the edge case that I'm concerned
>> about very often.
>
> There are currently very good reasons for clients to use the first
> model: it is a method of removing undesirable "fuzzy edges" from zoomed-
> in images.
>
> The alternative of scaling the outer edge, while not hitting this fast
> path, will not hit the other fast path either! (the other fast path is
> the one that allows a zero-weighted pixel at one end to be read from
> the image).

I'm generally in agreement with you. For the sake of completeness though,
I should point out that when zooming *out*, both models will match the
conditions for COVER paths. But then again, when you're zooming out,
particularly by a large factor, it is more appropriate to use a multi-tap
filter rather than bilinear scaling, so maybe that's not much of an
argument.

> NOTE: the method of scaling the centers of the pixels is generally
> wrong. The math is wonky: does scaling an image by 2 produce a 2*w-1
> image, or does it spread the pixels slightly more than 2 apart?
> Programs are going to disagree.

I'd suggest that if the highest layer software specifies a particular
scale factor, then that's what should be used, but if it requests a
particular destination size (e.g. "full screen") then that should be the
primary consideration even if it means the corresponding scale factor is
not the "obvious" one.

But this is all really a concern for the layers above Pixman, because the
starting fractional position and per-pixel increment is part of the
Pixman API. Pixman just has to do whatever has been asked of it. Just
because some of the ways the layers above Pixman do their calculations
are impossible for Pixman to optimise further shouldn't be a reason for
Pixman not to optimise the cases that it can do, especially when that
set of cases include many that use a scale factor of 1 on one axis.

Ben