On Thu, 14 Dec 2006 19:19:53 +0100, "David Turner" wrote: > 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). Ah, that's right. And that original work of yours predated a lot of what we have in cairo-perf. This will actually be nice to land as MacSlow recently tried out a recent cairo snapshot and was disappointed to not find as much speedup for cairo-dock as he had hoped. > 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 Yes, we definitely need some interesting splines, (we have one case that strokes a circle now, but it's such a simple shape and uses a stroke width so large that the cost of filling the region is likely overwhelming any cost of approximating the splines). > - 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. Oh, yes, those are definitely important. I had forgotten that was in your patchset, (the commit that introduces it has a commit message that starts off talking about reducing memory allocation, so I overlooked the important part in my last review). > 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. That would be great. The dock is just using a few SVG files, so vector data in those is generally just a simple search-and-replace away from being cairo C code. -Carl
Attachment:
pgptgiQHYP72t.pgp
Description: PGP signature