[Pixman] [PATCH 0/7] Faster pipelined ARM NEON bilinear scalers: 'src_8888_8888' and 'src_8888_0565'

[Soeren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

>> As far as I know, GdkPixbuf uses the equivalent of a bilinear filter
>> with four bits of precision. Once you scale more than 16x, banding
>> artefacts are clearly visible, but people don't normally complain about
>> its quality, and 16x scaling with bilinear interpolation won't look
>> great in any case, so if dropping precision to four bits really makes a
>> big performance difference, maybe we should just change
>> PIXMAN_FILTER_BILINEAR to do that.
>
> Reducing bilinear interpolation precision provides a lot more
> performance benefits for x86 (at least 7 bits would be better) and 4
> bits should be really the best. Anyway, who is going to decide whether
> the reduced precision is still ok?

Well, if no one has a problem with dropping the precision, then dropping
precision is OK, I guess.

> One can see a heavy use of bilinear scaling (over_8888_8_8888 fast
> path, also with optional horizontal flipping) on the web pages like
> this, especially if configured to animate 1000 fishes:
>     http://ie.microsoft.com/testdrive/performance/fishietank/
> I wonder how well pixman can actually perform there if it gets some
> good SSSE3 bilinear optimizations and starts utilizing all CPU cores
> (maybe trying OpenMP should be easy)?

For upscaling in particular, it may be interesting to look at a
different algorithm where two horizontally expanded souce lines are
cached and the destination scanlines are computed as a linear
interpolation between those two scanlines. This drops a little precision
because the two cache scanlines would be stored with 8 bits of color
depth and not 16 as we do now, but that probably would be completely
invisible.


Soren