Re: handle grapics with Document/View design

[Paul Kienzle]

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.
>
> Shai
>
>
>
> 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