octave-maintainers
[Top][All Lists]
Advanced

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

Re: Yet Another Plotting System for Octave


From: Alexander Barth
Subject: Re: Yet Another Plotting System for Octave
Date: Thu, 18 Jan 2007 17:42:16 -0500
User-agent: Thunderbird 1.5.0.9 (X11/20070102)

John W. Eaton wrote:
> [Since the graphics list is mostly dead, I'm moving this discussion
> to the maintainers list.  Please follow up to this sub-thread there.
> Thanks.  --jwe]
> 
> On 17-Jan-2007, Alexander Barth wrote:
> 
> | I wrote some plotting routines to visualize ocean model results
> | (although it can be used for other applications). I wanted to share
> | it because it might be useful for others as well. I called this
> | package Yapso, Yet Another Plotting System for Octave. It is
> | intended to be compatible with Matlab plotting commands. Yapso is
> | based on the OpenGL libraries and it uses (currently) the GLUT
> | toolkit (freeglut or openglut). Yapso is loaded dynamically in
> | Octave as oct-functions which allows a tight integration in Octave.
> 
> This looks good, but I'm curious to know why you chose to start from
> scratch instead of working on OctPlot.
Before I started with yapso, I tested octaviz and OctPlot. I liked the way how 
octaviz was loaded as
a dynamic library in octave. The data to plot can thus be easily transferred 
back and forth between
the octave and octaviz since they share the same address space. However, the 
objects behave as vtk
objects and to translate vtk properties in matlab properties would require IMHO 
a quite complex
translation layer. Therefore I think that a higher level of compatibility with 
matlab (in particular
with the graphics handle system) can be used by using a graphics library like 
OpenGL which is the
approach of OctPlot. But OctPlot communicates with octave using sockets which 
requires to design a
communication protocol between OctPlot and octave. Thus I was wondering if this 
additional
complexity could be avoided using the approach of octaviz with oct-functions.


> 
> Also, it seems that the code to handle plot properties is again
> tightly coupled with the code that renders the graphics.  Is that
> correct?  

Yes.

If so, how hard would it be to separate?

Where exactly do you want to draw the line of separation? Do you want to store 
the properties'
values as global octave structures and the graphics package would lookup their 
values in octave's
symbol table?

I would like to
> make these two parts separate so that it is easier to plug in
> different plotting libraries in the future.  The plot properties
> portion seems to me to just be a database problem, and it should be
> possible to implement it completely apart from any graphics library.
> 
> | What I missed from existing graphics packages was offscreen
> | rendering (matlab's -nodisplay option) which allows you to create
> | plots from a cronjob or from a webserver cgi.
> 
> Wouldn't Octave's default gnuplot graphics do this if you set the
> terminal type to something like "postscript" and the output to a
> "/dev/null" before doing any plotting commands, then used print to
> generate a file once you have a plot constructed?

I didn't tested this, but thanks for the hint. The main reason why I looked for 
a gnuplot
alternative was compatibility with matlab.

Cheers,
Alex


reply via email to

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