Re: [cairo] Better coverage from cairo performance suite (and some results)

["David Turner" <david freetype org>]

Hi Carl,

> One of the things I had been waiting for was an improved mechanism for
> detecting similar but not identical images in the test suite. I've now
> integrated the "perceptual diff" algorithm into cairo and it does help
> a bit, (though not as much as I was hoping). If someone wants to
> fiddle around with it more, that would be great, (just try removing
> some of the backend-specific reference images and then see if you can
> get the resulting failures to go away by tweaking pdiff.c).
>
ok, i'll try that next week
 
> Oh, and I've only committed the gradient improvements from your patch
> set. For the other stuff, I'd first like to see performance test case
> that demonstrate the benefit of the patches.
>
as far as I remember all my optimisations were done by profiling/benchmarking
the original "cairo-dock" application, i.e. the one that re-rendered each SVG
icon on each step (instead of scaling high-resolution bitmaps).

I don't have this code handy (it's on a partition on my computer in France,
and I'm currently in the US till next week), but from memory:

- generally speaking the SVG icons were full of bezier paths, and the
  decomposition optimization did yeld a rather important speed up in this
  specific algorithm (i believe it was at least a factor of 2, as reported
  by cachegrind; of course, I know this tool isn't always completely reliable
  but these was noticeable on the overall program nevertheless by a few
  percents).

  as you already said, it'd be nice to have such paths in the performance
  test suite. Only dealing with polygons is a bit limitating, in my opinion

- the cairo_path_fill_extents and cairo_path_stroke_extents were massively
  sped up, since they don't really need tesselation nor allocating large
  polygon arrays to return meaningful results. I believe it accounted for
  most of the speed up in this program's runtime.

  due to the way SVG works, librsvg very often needs to compute the extents
  of a given path before transforming and rendering it. In the case of the
  cairo-dock SVG icons, it does it for *every* path.
 
- for what it's worth, the inline assembly for "x_compute" did sped up the
  the old tesselator rather significantly for this specific test (I believe
  it was in the order of 15%, though this number was extracted through
  cachegrind, the overall speed improvement on the program itself was less
  than that)

  the trick is that the new inline assembly has special code to adapt to the
  range of the input data, which is really why it's faster than calling a
  general-purpose 64bits/64bits division function.

  the same tricks could be performed in normal C code for other platforms,
  especially the ARM which doesn't even have a 32-bit division CPU instruction !
  On this platform, a specially crafted muldiv function easily beats the
  compiler generated code for "a*b/c", under certain preconditions that are
  easy to check or ensure.

  I'll look at the new tesselator source code to see if it could be sped up
  similarly...

it might be interesting to create a cairo performance test based on the
paths and operations found in cairo-dock. I'll try to see if I can extract
these in a few weeks; I'll keep you informed.

By the way, any news why I can't properly subscribe to the cairo mailing list ?
It seems that's a problem for any list hosted on freedesktop.org.

Regards, and keep up the good work

- David

 
> Thanks again,
> 
> -Carl