[cairo] Very large number of lines

[Andrea Canciani]

On Tue, Aug 31, 2010 at 2:51 PM, necko necko <opustenom at hotmail.com> wrote:
> Thanks for the email.
> You were right about stroke the same line over itself. Therefore, I made a simple
> random coordinate generator that should more closely describe the problem
> I'm working on.
> Note that all the lines need to be shown in the pdf file (therefore I use translate
> which depends on min/max coordinate). The number of lines is from
> 20million-350million. This is the main reason I'm striving for speed (in
> processing and in displaying).
> Therefore, displaying a PNG file would be appropriate. Please consider the
> code below.
> The first translate option cairo_translate (cr, -229770, 26573); leads to
> execution time
> of around 7min, while the second one cairo_translate (cr, -429000, 35000);
> leads to
> execution time of around 1min. Is it because the invisible parts are not
> processed?

Invisible parts are faster than visible ones because they don't have to
be composited, but they require some processing (to determine visibility).
If your random data actually resembles your true data, consider a
simple clipping function.
In my attachment I get a big speedup when declaring NO_CLIP 0.
(It does just "trivial" clipping, lines completely above/under/right/left of the
visible region are not drawn, but there are some more lines that don't
pass through it
yet are not clipped with this check)

>
> For my application, everything within the bounding box (determined by the
> min/max coordinate) should be displayed.

That is obvious. The question is: do all the lines you draw with cairo pass
through the bounding box?

> I noted that the output is different when stroke() every 1000th or 100000th
> line.
> I thought this was because of the random number generator, but I tested it
> several times.

Don't use a variable seed. Stroking will be different because of compositing,
but the differences in your attachments cannot be explained this way.
Check again your output, making sure that you do not change anything else.
(Doing the same in my attachment I cannot reproduce your problem)

I tried to do minimum changes to your original file, but I couldn't
resist changing
the output.
Please play around a little with the defines in the file. You will see that:
 - disabling clipping times get much slower
 - rendering to pdf is not as crazy as before, since only a few thousands lines
   are actually in the bbox (about the 0.5%)
 - higher ITER_NOs are possible in reasonable amounts of time (image should
   scale linearly, pdf worsen when you start swapping)

Andrea
-------------- next part --------------
A non-text attachment was scrubbed...
Name: necko2.cc
Type: application/octet-stream
Size: 2452 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100831/e71fada9/attachment.obj>