Fast plotting?
Russell E. Owen
plots?
Our situation:
We are driving an instrument that outputs data at 20Hz. Control is via
an existing Tkinter application (which is being extended for this new
instrument) that runs on unix, mac and windows. We wish to update 5-10
summary plots at approximately 2 Hz and will be offering controls to
control the instrument and the plots, preferably (but not necessarily)
mixed in with the plots.
Ideally the package would create plots in the Tkinter application. But
we realize we're unlikely to get the speed we need that way. So we are
willing to have the Tkinter app send data to the plotting package (e.g.
via a socket) and have it display the plots in a separate process.
We started out with matplotlib, which is a wonderful package (and well
integrated with most or all GUI toolkits). Unfortunately it is just too
slow -- at least when driving plots integrated with the Tkinter app. (It
is getting faster and so are computers, so at some point this will be a
great way to go. But for now...)
Any suggestions?
-- Russell
raoul
the data to a file and have ploticus read it, but this can be easily
done using memory mapped files. It's a very fast package and it
produces very nice plots. SVG plots too. We use an svg viewer and then
reload the svg tree to rerender the plot.
Ron
William Park
> Can anyone recommend a fast cross-platform plotting package for 2-D
> plots?
>
> Our situation:
> We are driving an instrument that outputs data at 20Hz. Control is via
> an existing Tkinter application (which is being extended for this new
> instrument) that runs on unix, mac and windows. We wish to update 5-10
> summary plots at approximately 2 Hz and will be offering controls to
> control the instrument and the plots, preferably (but not necessarily)
> mixed in with the plots.
That's 10-20 plots per second. The only GUI plotter that I know is
'gnuplot', and I don't know if it will spit out anything at 10-20Hz.
For character plots (like old days terminal), it has speed but ugly to
look at.
>
> Ideally the package would create plots in the Tkinter application. But
> we realize we're unlikely to get the speed we need that way. So we are
> willing to have the Tkinter app send data to the plotting package (e.g.
> via a socket) and have it display the plots in a separate process.
>
> We started out with matplotlib, which is a wonderful package (and well
> integrated with most or all GUI toolkits). Unfortunately it is just too
> slow -- at least when driving plots integrated with the Tkinter app. (It
> is getting faster and so are computers, so at some point this will be a
> great way to go. But for now...)
>
> Any suggestions?
>
> -- Russell
--
William Park <openge...@yahoo.ca>, Toronto, Canada
Slackware Linux -- because it works.
Paul F. Kunz
> Russell E. Owen <ro...@cesmail.net> wrote:
> > Can anyone recommend a fast cross-platform plotting package for 2-D
> > plots?
> >
> > Our situation:
> > We are driving an instrument that outputs data at 20Hz. Control is via
> > an existing Tkinter application (which is being extended for this new
> > instrument) that runs on unix, mac and windows. We wish to update 5-10
> > summary plots at approximately 2 Hz and will be offering controls to
> > control the instrument and the plots, preferably (but not necessarily)
> > mixed in with the plots.
>
> That's 10-20 plots per second. The only GUI plotter that I know is
> 'gnuplot', and I don't know if it will spit out anything at 10-20Hz.
> For character plots (like old days terminal), it has speed but ugly to
> look at.
>
HippoDraw is quite fast and scriptable from Python
Patrick Ellis
disipyl is a wrapper around dislin. It includes a class that lets plots
appear inside tkinter frames. I did a quick test and the first demo plot
(run tkdisipyl.py) of a 180 point sine and cosine plotted at over 100 Hz.
http://kim.bio.upenn.edu/~pmagwene/disipyl.html
http://www.mps.mpg.de/dislin/
jdh...@gmail.com
unless you have special display hardware, I'm suspicious of these
numbers doubt . I once had a user post to the matplotlib mailing list
that xplt was refreshing at 1000 Hz. I think xplt drops plot requests
while requests are in the queue, so many of the loops in his iteration
were simply dropped. If the plotting library puts draw requests in an
idle event handler, accurate refresh rate numbers can be hard to
quantify.
JDH
Patrick Ellis
dislin doesn't seem to do that. I varied the number of points in the plot so
the drawing rate went from from 60 Hz to 144 Hz. It scaled linearly above
and below my 85 Hz screen rate. It wouldn't do that if it were dropping
plots. I think that computers are so fast that they can draw to the frame
buffer very quickly, but the slower screen refresh means only some of those
fully drawn frames make it to the monitor.
Even if you are correct, that is still drawing at 85 Hz and thus much faster
than the original poster needed.