> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
