[cairo] Better coverage from cairo performance suite (and some results)

[Carl Worth]

On Thu, 05 Oct 2006 11:32:37 -0700, Carl Worth wrote:
> Anyway, with the new tests in place, I've attached below the numbers
> from a run on my laptop. There's a fair amount of data here, and a lot
> of interesting analysis that could be done to find problems. I'll do a
> bit of that in follow-ups to this message.

Here's quick example of some simple analysis looking just at the
numbers for the paint operation and the image backend, (with an RGBA
destination).

I've dropped the "similar" source test results since for the image
backend they are obviously identical to the "image" source test
results.

First look at the SOURCE operator:

[ 61]    image-rgba             paint_solid_rgb_source-512     0.849  1.49%   100
[ 63]    image-rgba            paint_solid_rgba_source-512     0.845  0.95%   100
[ 65]    image-rgba             paint_image_rgb_source-512     2.538  1.11%   100
[ 67]    image-rgba            paint_image_rgba_source-512     2.048  1.80%   100
[ 73]    image-rgba            paint_linear_rgb_source-512    31.894  1.23%   100
[ 75]    image-rgba           paint_linear_rgba_source-512    32.248  1.92%   100
[ 77]    image-rgba            paint_radial_rgb_source-512    64.526  0.90%   100
[ 79]    image-rgba           paint_radial_rgba_source-512    69.896  0.62%   100

Good stuff:

 + It's obvious that whether there is alpha or not in the source is
   irrelevant to performance. That's as it should be.

 + Solid source patterns are faster than image surface sources.

Bad stuff:

 - Gradient computation is *really* slow, (which we did know about
   already at least). But now we know how slow. In the time it takes
   to compute a gradient image, we could have painted that image 15
   times (for linear gradients) or 30 time (for radial gradients).

Then look at the OVER operator, first looking at sources that contain
no alpha information (that is, they are fully opaque):

[ 60]    image-rgba               paint_solid_rgb_over-512     0.854  2.44%   100
[ 64]    image-rgba               paint_image_rgb_over-512     2.541  1.27%   100
[ 72]    image-rgba              paint_linear_rgb_over-512    32.004  1.18%   100
[ 76]    image-rgba              paint_radial_rgb_over-512    64.391  0.76%   100

Good stuff:

 + The times here are identical to the times above with the SOURCE
   operator. So "blending" that is actually just copying the source
   surface isn't any slower than just copying with the SOURCE
   operator. That's good news.

Then look at when there is alpha information in the source:

[ 62]    image-rgba              paint_solid_rgba_over-512     2.513  0.67%   100
[ 66]    image-rgba              paint_image_rgba_over-512     4.047  1.93%   100

These two cases slowed down, (which is expected of course). Did they
slow down more than expected? I don't know. The solid_rgba case is
about 3x slower than the solid_rgb case. The image_rgba case is about
1.6x slower than the image_rgb case. There are some people who have
spent a lot more time with our low-level compositing code than I have
(hint: I've spent none). They might be better able to reason about
those slowdowns to determine if they are expected or if they indicate
problems.

[ 74]    image-rgba             paint_linear_rgba_over-512    35.012  1.12%   100
[ 78]    image-rgba             paint_radial_rgba_over-512    65.185  0.71%   100

There's no significant slowdown to an alpha gradient compared to an
opaque gradient. That's not surprising given that we determined above
that all the time spent in gradients is in computing the gradient
itself. The incremental difference in times here (compared to the rgb
cases) is consistent with the incremental difference in the image
case.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061005/d7d36fc4/attachment-0001.pgp