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

[Carl Worth]

On Fri, 2008-10-31 at 12:22 -0700, Giles Westerfield wrote:
> I am relatively new to Cairo and this is my first time using the
> mailing list, so please be nice.

Hi, Giles. Welcome!

I hope you find that everyone here on the cairo list is quite nice, (and
nice to everyone regardless of how long they've been using cairo).

Thanks for the detailed explanation of the problems you've been having.
Let me first jump to the end of your explanation:

> should be using?  Could it have to do with the fact that I don't
> always supply even integer values to the drawing functions (like I did
> in the examples) so that Cairo is having trouble drawing between
> pixels?

This could very likely be the cause of some of the issues. We have
several fast paths in cairo that are used when the boundaries of the
geometry you are drawing lie entirely on integer values of the
device-pixel grid. So if the coordinate values you gave above are not
the same as the numbers you used when taking measurements, then that
could definitely throw things off.

And yes, as you guessed, the reason that the fast paths exist is that
cairo can use faster, nonantialiased rectangle-filling operations even
when the user has asked for antialiasing *if* cairo is able to
determined that the result will be equivalent, (which it can do for
horizontal and vertical strokes where the stroke width is an integer and
the strokes are positioned correctly so that the stroked boundary lands
on integer positions).

Now, in your case, you tried hinting to cairo that you don't actually
want any antialiasing. In some cases that could mean that cairo could do
things even faster than it would otherwise. But I don't think we have
fast paths to account for all of those.

For example, in a case like you gave:

	cairo_set_line_width(cr, 5.0);
	cairo_move_to(cr, 50.0, 50.0);
	cairo_line_to(cr, 1230.0, 50.0);
	cairo_stroke(cr);

Here you are are asking cairo to draw a horizontal line which in the
vertical dimension covers 4 rows of pixels fully, but covers the top and
bottom pixels only 50%.

The fact that the geometry is half-covering pixels means that the fast
path I discussed above will not be used. So that might be one issue
you'll want to examine. See here for more details:

	http://cairographics.org/FAQ/#sharp_lines

And as I mentioned, with CAIRO_ANTIALIAS_NONE cairo *could* implicitly
adjust the geometry to land on the nearest integer values of the pixel
grid without affecting the result. And that might allow the existing
fast paths to be used. But we don't have any such code in cairo
currently.

Meanwhile, that doesn't actually explain the problems you were seeing,
(I pulled that code example from the parts you were saying that were
actually fast). I just wanted to answer the question you asked about
whether using integers or not can make a difference. It definitely can.

The case of getting a performance difference between stroking a
rectangle and stroking 4 lines separately definitely sounds like a bug.
That's one that perhaps we could make a cairo-perf case out of and run
on a Linux machine with sysprof to see where the bottleneck is.

The case of the diagonal line being slower than a horizontal line might
be just the fast path discussed above. But I haven't looked closely at
the actual timings to see if that accounts for it. Again, profiling
would be useful here.

>   I'm hoping the answer is not that Cairo is just too slow to maintain
> 60fps in simple 2D applications.  Any suggestions or help would be
> much appreciated

I hope not too! I know I haven't given much in the way of concrete
suggestions yet, but hopefully we'll get more discussion and perhaps
someone will be able to replicate your results and investigate them more
closely.

I hope you do have lots of fun with cairo!

-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/3bfc20e1/attachment.pgp