[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