[Pixman] [PATCH 2/3] Optimize BILINEAR filter to NEAREST for identity transforms

[Soeren Sandmann]

> It seems to me that the cause of the problem is that the meaning of
> COVER depends on what the filter is: it means "there is enough space
> around the sample area for the chosen filter", which then becomes wrong
> when doing filter reductions.
>
> So maybe a solution would be to provide two separate flags:
>
>         COVER_NEAREST:  "there is enough space for a nearest filter"
>         COVER_BILINEAR: "there is enough space for a bilinear filter"
>
> These are unambiguous and because either there is enough space for a
> bilinear filter, or there isn't, they can be set independently of what
> the filter actually is.
>
> Code that currently depends on COVER generally also depends on filter,
> at least implicitly, so there shouldn't be any problem picking the
> correct version of COVER for existing fast paths.
>
> This would solve the problem because in the problematic case, the flags
> FILTER_NEAREST | COVER_NEAREST could be set, and the standard fast paths
> would run, but at the same time, bilinear/cover paths wouldn't be
> triggered because they would require FILTER_BILINEAR | COVER_BILINEAR.
>
> As a side effect, this also means we can drop the code that worries
> about what covering means when there is a convolution filter.

I tried implementing this scheme in the patch series that follows.

There is first a general cleanup of the analyze_extent routines. The old
code computed the transformed sample extent twice, once to determine
whether the clip was contained within the samples, and once to determine
whether the transformation of the destination rectangle, expanded by 1,
was contained within the 16 bit coordinate system.

The new code only computes the transformation once, and then it add the
absolute value of the 00 and 10 components to get a conservative
estimate of the transformed destination boundary. I'm especially
interested in review of this part, both of the code and of whether it's
actually correct mathematically.

Following that cleanup is Siarhei's change to affine-test and a change
to blitters test to make it use a bilinear filter occasionally. Then the
splitting of SAMPLES_COVER_CLIP and the bilinear reduction, followed by
Siarhei's patch to also do the reduction for 90/180/270 degree rotations
and integral translations.

The bug, for reference:

   https://bugs.freedesktop.org/show_bug.cgi?id=37421

Performance testing with Xephyr on a Core2 Duo @1GHz:

Current master:
*** ROUND 1 ***
---------------------------------------------------------------
Test: Test Xrender doing non-scaled Over blends
Time: 5.720 sec.
---------------------------------------------------------------
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 5.149 sec.
---------------------------------------------------------------
Test: Test Imlib2 doing non-scaled Over blends
Time: 6.237 sec.

With bilinear reduction:
*** ROUND 1 ***
---------------------------------------------------------------
Test: Test Xrender doing non-scaled Over blends
Time: 4.947 sec.
---------------------------------------------------------------
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 4.487 sec.
---------------------------------------------------------------
Test: Test Imlib2 doing non-scaled Over blends
Time: 6.235 sec.


Thanks,
Soren