Fast plotting?

Russell E. Owen

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.

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

Jul 19 '05 #1

raoul

I like Ploticus. It's a bit kludgy for integration, you need to send
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.

Jul 19 '05 #2

Ron

Russell E. Owen 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.

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

Have you looked at BLT?

http://sourceforge.net/projects/blt/
http://heim.ifi.uio.no/~hpl/Pmw.Blt/doc/

Jul 19 '05 #3

William Park

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.

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 <op**********@yahoo.ca>, Toronto, Canada
Slackware Linux -- because it works.

Jul 19 '05 #4

Paul F. Kunz

William Park <op**********@yahoo.ca> writes:

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

http://www.slac.stanford.edu/grp/ek/hippodraw

Jul 19 '05 #5

Patrick Ellis

William Park <op**********@yahoo.ca> typed:

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.

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

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/

Jul 19 '05 #6

jdh2358

Are you sure about these numbers? Most monitors refresh at 70-80Hz, so
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

Jul 19 '05 #7

Patrick Ellis

jd*****@gmail.com <jd*****@gmail.com> typed:

Are you sure about these numbers? Most monitors refresh at 70-80Hz,
so 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

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.

Jul 19 '05 #8