[cairo] [cairo-commit] 7 commits - src/cairo-path-fixed.c src/cairo-pdf-surface.c src/cairo-rtree.c src/cairo-rtree-private.h src/cairo-spline.c src/cairo-xlib-display.c src/Makefile.sources test/Makefile.am test/Makefile.sources test/meta-surface-pattern.pdf.argb32.ref.png test/meta-surface-pattern.pdf.rgb24.ref.png test/overlapping-glyphs.argb32.ref.png test/overlapping-glyphs.c test/overlapping-glyphs.pdf.argb32.xfail.png test/overlapping-glyphs.pdf.rgb24.xfail.png test/overlapping-glyphs.rgb24.ref.png test/scale-offset-image.pdf.xfail.png test/scale-offset-similar.pdf.xfail.png util/cairo-script
Chris Wilson
chris at chris-wilson.co.uk
Mon Jul 27 13:35:55 PDT 2009
On Mon, 2009-07-27 at 18:19 +0100, Chris Wilson wrote:
> I'm waiting on a callgrind of an extremely curve happy swfdec to get a
> more realistic measurement.
Just to elaborate here, callgrinding the swfdec TenaciousD trace which
is dominated by complex (curved) fills using the image backend:
Before (inclusive):
Total: 318,285,922,616
cairo_curve_to: 5,775,186,971
_cairo_path_fixed_curve_to: 1,661,998,661
_cairo_spline_init: 1,162,693,082
After (inclusive):
Total: 320,271,152,759
cairo_curve_to: 6,921,074,619
_cairo_path_fixed_curve_to: 2,807,886,309
_cairo_spline_init: 2,002,035,675
So the cost here is about 0.6% of overall instruction count.
If we subtract off the fill (217 billion) + stroke (2 billion) overhead
of 220,821,721,608, the cost of the extra checks is closer to 2%.
Considering the checks found zero cases of degenerate curves within that
trace, perhaps they are much, much rarer than I anticipated.
-ickle
More information about the cairo
mailing list