Thanks again for the suggestions, Carl.  I'll see what I can do to get my app running close to 60fps.  Also, I can confirm Soeren's comment on the bounding trapezoid issue applying to large rounded rectangles and curves, since I have experienced similar performance issues with those cases. I'll look forward to these issues being resolved in the near future, since they seem to be pretty crucial for anyone planning to do basic smooth animation with Cairo. Giles <div class="gmail_quote"> On Fri, Oct 31, 2008 at 1:48 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 13:34 -0700, Giles Westerfield wrote: > Thank you Carl and Vlad for your helpful explanations.  I'm also very > impressed with the general activity on the mailing list. </div>I'm quite glad to hear that. <div class="Ih2E3d"> > 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. </div>This is not a good idea. This will give you geometry that is unaligned by 0.5 device pixels in at least the following cases: * Using integer coordinates for your path and then doing cairo_fill. * Using integer coordinate paths for path and stroking with an even integer line width. Much better is to not try to do a global translation to "fix" things, but to instead provide geometry to cairo that is precisely where you want it. For example, use integer coordinates for fills, integer coordinates for strokes with even-integer line widths, and half-integer coordinates when appropriate for strokes with odd-integer line widths. Note that you'll also want to consider line caps and joins if you are stroking. The default line cap is LINE_CAP_BUTT so the stroke ends abruptly at the coordinate you specify. Meanwhile, with LINE_CAP_SQUARE the line would extend by one half the line width. So one or the other might make it easier to put the geometry exactly where you want it depending on how you organizae your code. <div class="Ih2E3d"> > 2.  Break long diagonal lines up into smaller diagonal lines so that > the overall needless computation is lowered. </div>This may very well help for now, yes. <div class="Ih2E3d"> > Any other ideas?  Should I keep antialiasing off? </div>Try it and see, I guess? One might imagine that using an A1 surface rather than an A8 surface could potentially be faster as well, (since without antialiasing you won't be using more than two values in your result anyway). But then again, it might very well not be. An A1 surface will use less memory, but there are packing and unpacking considerations, as well as the possibility of more hand-written optimized compositing paths having been written for A8 than for A1. So again, I think this is a case of try it and see. But really, the question of antialiasing or not should really be answered based on what you actually want to draw. Given that, we should then focus on fixing cairo to do that as fast as possible. This is much better than drawing something that's not what you want just because it might happen to be implemented faster for now. <div class="Ih2E3d"> >   Is it worth updating from 1.8.0 to the most recent 1.8.2 with > respect to these issues? </div>I wouldn't expect it to make any different for these specific issues, no. But we would still appreciate you upgrading and letting us know any feedback you might have on our new release. :-) Thanks, -Carl </blockquote></div>