Jin-chung> One would expect the following will fill up the plot
Jin-chung> window:
>>>> n=zeros(20000) n[::2]=1 plot(n)
Jin-chung> The plot "stops" a little more than half way, as if it
Jin-chung> "runs out of ink".
Jin-chung> It happens on Linux as well as Solaris, using either
Jin-chung> numarray and Numeric, and both TkAgg and GTKAgg, but
Jin-chung> not GTK. Is this due to some AGG limitation?
A bit more information on this problem - I just got this post from
Maxim on the Agg mailing list
Hi John,
You have this wierdness because your path is too long, it exceeds
the maximal limit of memory allowed for the scanline
rasterizer. It's 4196*1024 cells (pixels), or 67MB. I added this
limit in order not to crash the whole system in case if you or I
have an infinite loop of rasterizer::line_to. I'm not sure if it's
the best solution, but I don't see anything better. What is the
necessity to draw such long uninterrupted paths?
McSeem
This explains several of the "strange observations". The problem
occured when the axes limits were [-1,1] and not [-2,2] because in the
latter case the pixel coverage was smaller. It occured for plotting
solid lines but not for circles for the same reason.
Probably the best solution is to break long line paths into multiple
paths in the agg backend. It should be a pretty rare event - there
aren't too many plots that try and cover that many pixels with lines,
but it does happen and should be accounted for...
JDH