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
Attachment:
pgpqnS3BTnP00.pgp
Description: PGP signature