[cairo] Cairo efficiency with massively long lines

[Damon Chaplin]

On Thu, 2007-02-22 at 13:09 -0500, Paul Davis wrote:
> Greetings Cairo folks. A few people here were incredibly helpful with my
> last questions about planning the move of Ardour (http://ardour.org) to
> a Cairo-based canvas. We've run into another issue with our current use
> of GnomeCanvas, and I wanted to check that Cairo would handle it
> properly before I waste time trying to find a workaround.
> 
> Will Cairo efficiently render a line that has two coordinates at zero
> and (say) 2^32-1 or 2^64-1 (on the x-axis) ?

You might run into cairo's fixed point integers limit (internally it
uses a 32-bit int with 16 bits for the integer value and 16-bits for the
fractional part).


> The current GnomeCanvas code generates a "micro-tile array" (UTA; a list
> of 32x32 pixel cells) to describe the areas of the image that need to be
> re-rendered, and with a line like this, the UTA is obvously huge - it
> correctly reflects the fact that the area to be re-rendered is enormous.
> As a result, when our canvas has numerous of these objects on it, any
> operations that cause a recomputation of what needs to be rendered are
> dog slow.
> 
> Does Cairo's internal implementation correctly handle this kind of
> situation? Presumably, the correct limitation is to not compute a UTA
> that extends beyond the current visible bounds of the
> image/canvas/pixbuf. I'd appreciate clarification on how Cairo does
> this.

My inclination would be to write your own custom canvas items that only
draw what is visible. Though I hope someone who knows more can give a
definitive answer.


(If you want to try to use my GooCanvas widget for ardour, I'd be
willing to help out with that. C++ bindings are being written for it.)

Damon