[cairo] Performance stroking lines

[Dan Amelang]

On Nov 14, 2007 2:35 PM, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> Hi,
> ... (lots of description and data about a performance problem) ...

Hi Peter, thanks for gathering all this data for us to work with.

Unfortunately, from your profile, I don't see any obvious, low-hanging
fruit for improvement. At the top of your profile, you have basically
the cairo/X rasterization and compositing/fill functions, which is
good in the sense that your program is spending time doing "real work"
and not doing "needless overhead".

Speeding up rasterization and/or compositing any large amount would
entail a significant amount of work (there has been talk about this
recently on the list). And from what I get your email, you probably
aren't very interested in hardware acceleration, since you mention
that your users often have not-so-powerful hardware.

So, the fall-back answer is to find some way to do less work (avoid
unecessary work, cache the results of previous work, etc). It might
help to share with us some of your drawing code. Maybe we can spot
areas where this can be done. One can often cache rendering results on
a separate image surface and just re-composite that surface each time
you draw (e.g. the rendering for a whole "component" could be rendered
and cached on an off-screen surface).

Some strange things I saw in your oprofile reports (which are likely
just my own confusion...oprofile reports have confused me in the
past):

> (GDK Double buffering on, cairo image surface)
>
> 90623    21.7340  processor                processor                (no symbols)
> 24089     5.7772  libfb.so                 Xorg                     fbCopyAreammx
> 16343     3.9195  libfb.so                 Xorg                     fbRasterizeEdges
> 16316     3.9130  libfb.so                 Xorg                     fbCompositeSolidMask_nx8x8888mmx

Why would your machine be spending all that time rasterizing and
compositing in the X server if you are using an image surface for
rendering?

In addition, on all of your profiles, the total % for cairo/X lies
between ~5-12%. Again, it's probably my own oprofile ignorance, but
might that point to something else being the bottleneck? That 40%
samples in "processor" makes me a little nervous...

It also might be useful to generate one of the other types of oprofile
reports, I forgot what all are available and what they do, but a
different view/angle on the data might help.

Dan