Siarhei Siamashka <siarhei.siamas...@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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman