[cairo] Performance of rendering long, angled lines in Cairo

[Giles Westerfield]

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


On Fri, Oct 31, 2008 at 1:48 PM, Carl Worth <cworth at cworth.org> wrote:

> 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.
>
> I'm quite glad to hear that.
>
> > 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.
>
> 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.
>
> > 2.  Break long diagonal lines up into smaller diagonal lines so that
> > the overall needless computation is lowered.
>
> This may very well help for now, yes.
>
> > Any other ideas?  Should I keep antialiasing off?
>
> 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.
>
> >   Is it worth updating from 1.8.0 to the most recent 1.8.2 with
> > respect to these issues?
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20081031/b8b718d8/attachment.htm