[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handle grapics with Document/View design

From: Paul Kienzle
Subject: Re: handle grapics with Document/View design
Date: Sun, 30 Oct 2005 22:13:17 -0500

Octave needs control over axis limits because we may knowingly plot data which goes beyond the bounds of the default view. Users should be free to zoom out to the complete view. Another example is plotting a normalized gaussian whose width is defined by the value of a dial. As the user changes the dial, they want to see the gaussian get wider and the peak get lower, which they wouldn't see if the axes were controlled entirely by the graph.

Octave needs control over the placement of the tic positions and labels, otherwise we can't write functions such as normplot() or any other function that relies on tics().

Users will certainly want to control the values of the contours for some applications (e.g., elevation on maps). They may also want to perform numerical operations on the contours chosen, such as estimating the area between contours.

So yes, please continue to submit useful graphics operations to octave so that the graphing engine doesn't have to be as smart. And make sure they get included... :-)

- Paul

On Oct 30, 2005, at 9:59 PM, Shai Ayal wrote:

A thought on the Document/Viewer approach to handle graphics:

What should be left for the Viewer to do? This is a decision which
will have quite an impact. How "smart" should the viewer be?I will
demonstrate with an example:
The viewer should be able to set the axis limits to allow for mouse
zoom (an essential feature IMHO).
But should the Viewer be exclusively responsible for the axis limits?
will the command axis("auto") be preformed by octave or the viewer?
should the tick mark locations (and labels) be decided by the viewer
or octave?

If you leave it to the viewer you will get different behaviour
depending on the viewer. However doing it in octave means still more
work ... Also, for gnuplot, the de-facto viewer it means duplicating
on octave all it's "smart" features (such as axis limits and tics) and
making it into a "dumb" viewer. In essence all octave will be using is
gnuplot's terminals and none of it's other algorithms.

If this is the way to go, I have already submit way back a contouring
algorithms to replace gnuplot's contour, and I am willing to submit
axis limits & tic algorithms from octplot once they become stable.


On 10/26/05, Paul Kienzle <address@hidden> wrote:

On Oct 25, 2005, at 8:23 PM, John W. Eaton wrote:

On 26-Oct-2005, Teemu Ikonen wrote:

| The reason I'm asking is that I recently tried the python
| package matplotlib, which I think would be an excellent plotting
| backend also for Octave.

I think that would be a nice addition.  Does matplotlib do 3D plots?

No, but the 2-D plots are gorgeous.  There are performance issues
with pcolor, but I hope to have those addressed in the next couple
of months.

There has been some effort put toward a VTK binding, but we already
have that with octaviz.

- Paul

reply via email to

[Prev in Thread] Current Thread [Next in Thread]