[MATRIX-SIG] [long] A NO-Proposal for a plot-package

Geoffrey Furnish furnish@acl.lanl.gov
Mon, 21 Jul 1997 08:56:55 -0600 (MDT)


Konrad Hinsen writes:
 > > First some of the things I think a ubiquitous plotpackage should cover:
 > >...
 > 
 > That's a long list, although of course all that is desirable. But
 > we need something shorter for getting started!
 > 
 > So let's look at this from an implementation point of view and see
 > what is essential and how much development can be parallelized.
 > 
 > An essential part seems to be the intermediate representation of
 > "graphics" (which needn't be limited to plots) in terms of elementary
 > objects such as lines, markers, circles etc. This must be defined
 > first. Then work can progress in two directions:
 > 
 > 1) Low-level drivers, which turn the intermediate representation
 >    into images, Tk objects, PostScript files, etc. They would also
 >    take care of animation and editing (where it makes sense).
 > 
 > 2) High-level plot-to-graphics code. This would consist of one
 >    module per type of plot, and the modules would to a large
 >    degree be independent of each other.
 > 
 > For plain plotting and also animation, the interfaces between the
 > modules seem straightforward. Editing, on the other hand, is
 > not so trivial, since the high-level plot objects must be able
 > to turn graphical information back into numerical data, which is
 > not always possible, at least not uniquely (think about editing
 > a contour plot!). Inquiry (getting the value for the point under
 > the mouse cursor, for example) is somewhere in between.
 > 
 > > 1) Use standard or at least very portable graphics-libraries: If the
 > > effort is done to build a new plot-system it should be availabel with
 > > some drivers on all platforms, where Numpy is availabel. I think the
 > 
 > My first attempt at a general low-level driver would be Tk canvases,
 > since Tk is widely supported. Together with PostScript for printing,
 > this would already make many people happy. Next is OpenGL, and then
 > the system-specific libraries.

There are widespread complaints about the run-time performance of Tk
canvases.  This figured prominently in the decision to make a seperate
Tk-aware plotting widget in PLplot.  Besides our own experiences, I
have heard many other people complain about the performance of Tk
canvases (in contexts other than scientific plotting).  Also, besides
performance, you also face color management issues if you adopt Tk
canvas.  My opinion, and I think this is reflected in the
architectures of other plotting packages as well, is that good
plotting packages need to be able to manage their own color maps.
Cooperative behavior is good to avoid "color flashing", but at some
level, good rendering depends on good color control.

 > But now for the really important question: do we have enough manpower
 > to complete such a project to a useful stage in a reasonable amount of
 > time? Yes, that's a call for volunteers. Starting with myself, I would
 > be able to do some useful work, but not necessarily on a predictable
 > time scale.

It seems to me that all this discussion about plotting is somewhat
orthogonal to the issues involved with making a good matrix facility.
Plotting is a natural client of a matrix facility, but is otherwise
independent.  I don't see major issues in plotting which can
reasonably be expected to strongly influence matrix design or
implementation issues.

I wonder if it might be more appropriate to initiate a plotting-sig,
or a "scientific environment sig", or some such, and move the plotting
discussion which is not specifically matrix-sig-design-influencing,
off to said new sig.

I am /not/ volunteering to be the sig owner, but I do think it would
be better to segregate these discussions in that way.  Opinions?

-- 
Geoffrey Furnish                email: furnish@lanl.gov
LANL CIC-19 POOMA/RadTran       phone: 505-665-4529     fax: 505-665-7880

"Here are your ball-peen hammers.  Now go malleate some heads!"   -Jim Morel

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________