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

[Carl Worth]

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20081031/66e2aa2b/attachment.pgp