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

[Giles Westerfield]

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


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

> 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!
>
> Ah, of course. Thanks for explaining that Vlad.
>
> > 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...
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20081031/8136b66a/attachment.htm