## matplotlib-users

 [Matplotlib-users] plot dense and large arrays, AGG limit? From: Jin-chung Hsu - 2004-07-26 20:51:20 ```One would expect the following will fill up the plot window: >>> n=zeros(20000) >>> n[::2]=1 >>> plot(n) The plot "stops" a little more than half way, as if it "runs out of ink". It happens on Linux as well as Solaris, using either numarray and Numeric, and both TkAgg and GTKAgg, but not GTK. Is this due to some AGG limitation? JC Hsu ```
 Re: [Matplotlib-users] plot dense and large arrays, AGG limit? From: John Hunter - 2004-07-28 13:03:22 ```>>>>> "Jin-chung" == Jin-chung Hsu writes: 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? Hi Jin-chung, This is indeed an agg problem. It is not a limitation in the sense of 'n is too large'. It looks like a bug in agg but it is too early to say. For example, this is OK >>> plot(n) >>> ax.set_ylim((-2,2)) as is >>> plot(n, 'o') or >>> plot(rand(20000)) Ie, the problem seems to occur when plotting solid lines where many of the y values are similar, but is not a problem with the length of n, per se. I was able to reproduce the bug in pure agg c++ and posted to the agg mailing list. Maxim (agg author) is on vacation, but I suspect he'll provide some insight when he returns. Thanks for letting me know, JDH ```
 Re: [Matplotlib-users] plot dense and large arrays, AGG limit? From: John Hunter - 2004-08-09 20:16:55 ```>>>>> "Jin-chung" == Jin-chung Hsu writes: 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 ```