thewtex wrote: >>> Main issue is Matplotlib's performance. I'm trying to plot a current >>> trace from a physics experiment, containing about 300,000 data points. >>> In LabVIEW, one can easily browse through a data set like this, but I >>> haven't been able yet to get such a good performance with >>> IPython+Matplotlib. Especially scrolling/panning through the data is >>> sluggish. (Anyone knows how to add a scrollbar for this instead of >>> panning with the mouse, btw?) >>> >> http://matplotlib.sf.net/examples/embedding_in_gtk3.py shows an >> example using a scrolled window. >> >> You could also use the "clipped line" approach to pass in a custom >> class that only plots the data in the current view limits defined by >> timemin, timemax. See >> http://matplotlib.sf.net/examples/clippedline.py. This example >> changes the marker and line style depending on how many points are in >> the view port, but you could expand on this idea to do downsampling >> when the number of points is too large. > > Hi Onno and JDH, > > JDH, I have just started using matplotlib and love it. Thanks so much for > your > work. > > I have come across the same performance issues. My vote is for bringing > clipped line back and even making it the default. A check may be needed in > the > constructor to make sure it is sorted, but I think it is worth it. If the > program is used for its primary original intent (plotting), the vast majority > are going to be increasing in x. > > I am including a class based on ClippedLine that does decimation. Please > reply > if you have improvements and please consider putting something like it in the > code. This probably should not be used as default, though, because it may > not > be what the user expects. For example, if Onno is looking for very short > duration spikes, they will not get plotted. That is the nature of the > decimation beast. And, the filter requires the x data to be equally spaced. > > With decimation you not only get performance increases, but you also get rid > of > the smooching that occurs if the data is not monotonic so you can actually > see > something.
I agree that exploration of large data sets is an important application, and that we need to speed it up. A couple days ago I added automatic subsetting (but not decimation--although this could be added easily) to image drawing, and that made a big difference for panning and zooming using imshow or pcolorfast with regular grids. An easy, built-in interface makes sense for line/marker plotting as well, but it will take some thought to figure out exactly what that interface should be. The line plotting case (including things like scatter) is more complicated than the image. Probably optimizations should be specified via kwargs, not by default. Clipping should not be to points inside the xlim, but should include one more point on each side so that lines go to the edge of the box. Eric ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
