[cairo] scaling performance test of cairo library

[Siarhei Siamashka]

On Tuesday 08 February 2011 16:02:27 Andrea Canciani wrote:
> On Tue, Feb 8, 2011 at 2:23 PM, Siarhei Siamashka
> 
> <siarhei.siamashka at gmail.com> wrote:
> > On Tuesday 08 February 2011 06:52:02 cooolheater wrote:
> >> Hi,
> >> I'm developer of mobile browser using webkit with cairo library.
> >> Recently, I did performance comparing test between cairo 1.10.02 and
> >> skia library.
> > 
> > Thanks for your benchmarking data. What kind of hardware have you used
> > for running this benchmark? And because you are using cairo image
> > backend, the version of pixman library is also important because it is
> > actually doing all the scaling work.
> > 
> >> The performance of compstion and rotating seems similar,
> > 
> > Performance of rotation in pixman should be horrible right now, don't
> > know if I should be happy to know that skia seems to be just as bad :)
> > 
> > What kind of rotation are you are interested in? The following patches
> > should help with some types of rotation, and can be extended if needed:
> > http://lists.freedesktop.org/archives/pixman/2011-February/000970.html
> > 
> >> but scaling performance of cairo library seems quite low.
> > 
> > On non-SIMD capable processors, cairo/pixman should have bilinear scaling
> > performing roughly as fast as the other good implementations, so I assume
> > that some kind of SIMD is supported on your target system.
> > 
> > A problem with bilinear scaling performance in pixman is that it does not
> > have SIMD optimizations yet. That's something that I'm currently looking
> > into, at least for ARM NEON.
> > 
> > Also your benchmarks show that the overhead before reaching actual
> > scaling code is much lower with skia as can be seen for very small sizes
> > of images. It's still questionable how much such overhead affects real
> > use cases, but I'm expressing concern here from time to time whenever I
> > see the patches which seem to be increasing this overhead in pixman more
> > than necessary.
> 
> Profile data would be needed to confirm this, but my guess is that most of
> the overhead is actually in cairo.

Well, having another look at the code, I think that the results for small
image sizes are not reliable. The timer gets started/stopped just around 
cairo_paint() and does not take into account the initial setup. Depending on
implementation details, the actual work processing these scaling settings
parameters may be either postponed till the paint operation itself, or done
immediately.

Also the use of scale factor 2.0 is not a very good choice for general scaling
performance comparison. Because theoretically it may be special cased and work
faster than scaling with arbitrary scale factors in either of the libraries.

> > The only surprising thing in your data is that skia seems to have really
> > poor performance for nearest scaling, but probably they just primarily
> > focused on making bilinear scaling fast.
> 
> The cairo bilinear/nearest ratio looks more surprising to me.
> What is the reason for a 40x slowdown?
> I didn't expect the generic path to be so much slower than fast paths.

It's more like 35x slowdown, but this is not very surprising. For nearest 
scaling it's just a single read from one place and a single write to another
place per pixel. For bilinear scaling, in order to get a single destination
pixel, we are reading 4 source pixels, recalculating weights, doing lots of
multiplications, additions and shifts. That's a lot more operations and being
that much slower is pretty normal for a general C implementation. SIMD is
expected to perform really well on such workloads, but surely can't match the
performance of nearest scaling either.

-- 
Best regards,
Siarhei Siamashka