[cairo] Performance stress-case (librsvg)

[Kalle Vahlman]

Hi!

I spotted this awesome background by Máirín Duffy on p.g.o:

  http://mihmo.livejournal.com/#entry_34708

and immediately proceeded to grab the svg. Shortly after that I viewed
my Pictures folder in nautilus and it looked like it hanged. I waited
a while and it revived from the coma by itself. I pondered what could
be the cause for some time.

Then I thought to try and load the svg with rsvg-viewer and what do
you know, it took almost minute and a half to render! Obviously this
can be to some extent attributed to the size and complexity of the svg
and the relative slowness of my machine, but _minute_ and a half is a
bit too much.

For example, this is what happens with the world_map test on my machine
:

[ # ]  backend-content                    test-size min(ticks)
min(ms) median(ms) stddev. iterations
[  0]    image-rgba                  world_map-800  726304090 1038.653
1042.105  0.52%  14
[  0]    image-rgb                   world_map-800  727188404 1039.917
1044.456  0.68%  11
[  0]     xlib-rgba                  world_map-800 1086229484 1553.365
1569.519  0.76%   6
[  0]     xlib-rgb                   world_map-800 1107742545 1584.130
1596.357  1.36%  12

So it is nowhere near this, although that data is not really trivial either.

Looking a bit into where the time is spent, I see the bulk of the time
goes to cairo_paint() calls:

rsvg_node_draw                             0,00  82,34
  _rsvg_node_draw_children                 0,00  62,02
    rsvg_pop_discrete_layer                0,00  60,69
      rsvg_cairo_pop_discrete_layer        0,00  60,66
        cairo_paint                        0,00  32,45
        cairo_paint_with_alpha             0,01  23,41
        rsvg_filter_render                 0,01   4,65

Both cairo_paint() and cairo_paint_with_alpha() progress directly
through the stack to _cairo_pixman_composite calls (respectively):

    cairo_paint
0,00  32,45
      _cairo_gstate_paint
0,00  32,45
        _cairo_surface_paint
0,00  32,44
          _cairo_surface_fallback_paint
0,00  32,43
            _clip_and_composite_trapezoids
0,00  32,42
              _cairo_surface_composite
0,01  32,41
                _cairo_image_surface_composite
0,01  32,39
                  _cairo_pixman_composite
0,01  32,36
                    _cairo_pixman_composite_src_8888x8888mmx
32,32  32,32

  and

    cairo_paint_with_alpha
0,01  23,41
      _cairo_gstate_mask
0,00  23,41
        _cairo_surface_mask
0,00  23,41
          _cairo_surface_fallback_mask
0,00  23,41
            _clip_and_composite
0,00  23,41
              _cairo_surface_mask_draw_func
0,00  23,41
                _cairo_surface_composite
0,00  23,41
                  _cairo_image_surface_composite
0,00  23,41
                    _cairo_pixman_composite
0,01  23,40
                      pixman_compositeGeneral
0,02  23,39
                        mmxCombineMaskU
14,71  14,71
                        fbFetch
0,00   6,52
                          fbFetch_a8r8g8b8
6,52   6,52
                        mmxCombineOverU
2,15   2,15

Now, I'm not sure if these provide any useful data about *what* is so
slow there, but I hope someone with more grasp on the internals of
both cairo and librsvg can comment on that.

In any case, the svg should be a nice test case for performance, given
that it is obviously not a trivial one to render.

Full sysprof trace is available from:

  http://iki.fi/zuh/rsvg-view-qn.sysprof

P.S. The other major hot spot in the trace is the blur filter:

  rsvg_node_path_draw                                    0,00  19,71
    rsvg_render_path                                     0,00  19,71
      rsvg_cairo_render_path                             0,00  19,67
        rsvg_cairo_pop_discrete_layer                    0,00  19,07
          rsvg_filter_render                             0,00  12,60
            rsvg_filter_primitive_gaussian_blur_render   0,00  12,59
              box_blur                                  12,48  12,48

Just in case anyone wants to look at that too ;)

-- 
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi