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 _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
