RE: [Plplot-general] Using plplot in an interactive environment

[Geoffrey F. <fu...@ac...>]

Andreas Dietrich writes:
 > I'm working on a little python module to provide interactive plotting
 > capabilities. Currently I have the following problem.
 > 
 > The xwin driver will not start redrawing the window before plend()
 > is called. Now the problem is, plend() will block until the window
 > is closed (as expected). 

I believe the X windows driver will process the X event loop whenever
a page advance is required.  But yes, I agree it can be very
frustrating when the window becomes unresponsive while the process is
compute bound.

We have considered many options over the years, including some like
what you suggest below.  You can also add a threaded xwin to the list,
so that perhaps the X driver process the X event loop continuously in
a thread in the background.  

I think a key question here is to understand exactly what you are
after.  Are you trying to keep the window responsive even when your
client program is compute bound?  In this case you absolutely must
bust the display code out to a seperate process (using some form of
IPC or another), or drop the event handling code into a thread.  One
or the other, and neither one is currently done exactly in PLplot at
this time.

However, perhaps all you really want is for the output window to be a
bit more useufl and "alive" or "reactive" during moments when the user
wants to interact with it.  In this case, you might be very satisifed
with the plframe widget, which uses the xwin driver, but packages it
as a Tk widget.  Several of us have found this interaction paradigm to
be extremely satisfying as an "interactive PLplot" capability, and it
provides many possibilities for a nice looking GUI on a scientific
code. 

If you want to do this in a Python program, you'll need to build a
python that includes PLplot.  This is documented in the
bindings/python/readme file, but it is admittedly a nontrivial
undertaking.  If you get that done, however, you might try out
pytkdemo to get a feel for what the Python plframe widget support can
bring to your code.  It has some rough edges, for sure, but overall I
think you might find this very satisfying.

We have some work underway to simplify the process of introducing
PLplot and plframe in particular, to python, without having to do all
the complex stuff explained in bindings/python/readme, but this work
is outstanding at this time, and we cannot promise an ETA.  There are
some fairly complex issues involved.

 > I considered the following solutions:
 > 
 > a)Fork whenever a plot has to be drawn. 
 > [...]  Not good.

I agree, forking your whole compute/data intensive code just to make a
plot, sounds like massive overkill.

 > b) Fork a plotter on startup. Send commands and data to it via
 > IPC. Let it fork more processes do handle each window. No obvious
 > problems, but needs a IPC mechanism to be designed and implemented.

Right.  This is sort-of how the OS/2 PM driver works, and I think it
serves a valuable role in that environment.  A key difference is that
the OS/2 PM driver sends data through an OS/2 named pipe, to just a
single plot server process.  I think it was called pmserv or something
like that.  Anyway, you start that once, and then the OS/2 PM driver
just sends it plot commands over the named pipe (like a Unix fifo).
This notion could be carried over to X as well, and I agree there
could be some major benefits to this model.  The IPC could be done
with either sockets or shared memory, and I think this idea has some
real merit.  The OS/2 PM driver could serve as an excellent stepping
stone in the construction of a standalone X driver, as well.

One significant drawback of this approach, is that many people
currently capture the X window id from PLplot's xwin driver, and use
it for other stuff too (or vice versa).  There have been posts to the
PLplot mailing list over the years that have made it clear that some
people are sharing the X window betwen PLplot and the rest of their
code, for whatever purposes they may have for such activity.  I think
this would be hard or perhaps next to impossible with this bifurcated
X driver notion.  But maybe not.  X has this "reparenting" notion, so
that actually X windows in a single app can actually be driven by
seperate processes.  So I don't know, perhaps there could be joy down
this path too.

All in all, its a very complex set of issues.  I am pesonally inclined
to think that a freestanding X driver operating analogously to the
OS/2 PM driver, would be a good thing for PLplot, and implemented over
sockets.  But this is not under development at this time.

 > c) Generate immediate plmeta-represenation in the main process and
 > fork()/exec(plrender) to display it. This could even provide interactive
 > data readout via fifo. Drawback: plrender cannot read from a pipe or a 
 > fifo(fgetpos fails). This means
 > 
 >    + temporary files have to created
 >    
 >    + An existing plot-window cannot be updated or reused. Plrender will read
 >    to EOF and then wait for the window to be closed.
 >     
 > I really like c) because of its simplicity and because it is _almost_
 > working as I want. Now if just plrender could read from a fifo. 

I'm not sure how feasible it is to make plrender read from a fifo, or
a socket.  It might actually be easier for you to write your own
Tk-based plrender-like app that uses Tcl's "file event" thing to just
automatically notice when new plmeta files are "deposited" by your
main program.  So you could have a deal where you spin off (fork/exec
perhaps, or maybe just start it before by hand seperately) your Tk based
rendering engine.  Then you run your code and it drops distinct
metafiles from time to time, and then your one renderer notices when
they show up and renders them in turn.

But I wonder if you really need this.  It sounds like you might be
able to be happy with a PLplot-enhanced python, and using the
Plrame.py widget support.

 > Looking at plmeta.c it seems that writing to a pipe was considered
 > (but not finished, at least one more if(isfile) is needed), so it
 > may be possible to patch plrender to work from a pipe (perhaps
 > losing a feature or two), but I do not yet understand the code good
 > enough. Does anybody out there understand the design of plmeta
 > files?
 > 
 > Any other comments?

I'd probably look at the OS/2 PM driver if I was gonna start a new
seperate-process display capability.  I doubt plmeta and plrender are
really the most suitable starting place.  In particular, those codes
may be sufficiently complex that it might be challenging to keep them
doing their current job stably while adding in this fifo business.  

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041