Thank you Carl and Vlad for your helpful explanations.  I'm also very impressed with the general activity on the mailing list. After reading your explanations, a lot of issues I've been noticing (in addition to the ones I previously mentioned) make more sense.  I am indeed doing a lot of drawing at non-integer pixel values.  It is a bit troubling to hear that there isn't really an easy solution at this point, but it seems I could do the following things to improve performance: 1.  Before doing any drawing, translate the entire surface by .5 pixels horizontally and vertically so that even integer values land on the boundaries between pixels and not in the middle of pixels.  Also, I should use only integer values for line widths. 2.  Break long diagonal lines up into smaller diagonal lines so that the overall needless computation is lowered. Any other ideas?  Should I keep antialiasing off?  Is it worth updating from 1.8.0 to the most recent 1.8.2 with respect to these issues? Thanks again for your help! Giles <div class="gmail_quote">On Fri, Oct 31, 2008 at 1:03 PM, Carl Worth <<a href="mailto:cworth@cworth.org">cworth@cworth.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Fri, 2008-10-31 at 12:41 -0700, Vladimir Vukicevic wrote: > But since you're hitting the general case, the first thing that happens > is that a large temporary surface big enough to encompass the set of > trapezoids to be rendered is created -- in your case somewhere around > 1200 x 950.  The trapezoids are rendered to that, and then that surface > is used as a mask for the final filling operation.  You can see the > problem -- that's a large surface, and you're both rendering to it and > then compositing with it, not to mention creating/destroying it just to > execute that simple stroke! </div>Ah, of course. Thanks for explaining that Vlad. <div class="Ih2E3d"> > For the diagonal case, it's not possible to optimize it as rectangular > fills, so you end up creating the large temporary surface which can > contain the entire diagonal line (which is essentially the worst case > scenario). > > big-diagonal-lines would actually make a great perf test... </div>Yes, we definitely need to do better on that. Even without a big change to the rasterizer it should be obvious that even just breaking up the geometry into smaller segments would perform much better, (as the smaller intermediate masks would no longer include large regions of useless compositing). So we should start tracking this in cairo-perf and see what we can do to make this case faster in cairo itself, (without the application needing to slice up its geometry in silly ways). -Carl </blockquote></div>