[Top][All Lists]

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

Re: graphics issues

From: Quentin Spencer
Subject: Re: graphics issues
Date: Tue, 03 Oct 2006 15:34:29 -0500
User-agent: Thunderbird (X11/20060913)

Shai Ayal wrote:
On 10/3/06, Quentin Spencer <address@hidden> wrote:
Joe Koski wrote:
> on 9/29/06 11:38 AM, John W. Eaton at address@hidden wrote:
>> On 29-Sep-2006, Shai Ayal wrote:
>> | While OpenGL will take care of all the 3D stuff, you still have all
>> | the "graph" things to take care of -- axes, tics, legends, titles
>> | etc... All are "trivial" but with many small annoying details (auto
>> | axes limits and ticks is quite hard IMHO). this is quite a lot of
>> | work. octplot is under development for more than 2 years (although
>> | it's not very intensive development) and these things are still far
>> | from prefect
>> I agree that these little details, while each may seem like a simple
>> problem, add up to a major headache, especially given that the code
>> already exists in other places (gnuplot, plplot, NCAR graphics, etc.).
>> My preference would be to use some existing code if at all possible,
>> but I don't know where to find something that is relatively easy to
>> use and not closely tied to a specific plotting package.
>> jwe
> A couple of points. I have the post-processor called smokeview for the NIST > FDS code (see http://fire.nist.gov/fds/ ). It is an OpenGL application and > runs on my Mac (without X11) with 3D displays that I can rotate, change the > viewpoint, etc. without the delays or "inertia" that feel when I'm using > other applications. Whether a graphics language can run natively on many > platforms, including Windows and Macs, should be a major consideration. > Apparently OpenGL has that capability, but I'm no expert, so maybe someone
> can comment on that.
> Second, the plplot folks have been very active lately, enhancing the
> package, so maybe plplot should be reevaluated, especially since there is > already an octave binding included in the plplot distribution. The plplot > folks are adding a wxwidgets driver. Is that tied to X11? The "widgets" in > the name sure sounds like X11 is involved. What is the potential impact of > wxwidgets on octave? I did play with octave/plplot a year or two ago, and > found myself going back to gnuplot. Back then, plplot's main use was for
> salvaging the graphics on old legacy codes that had outlived their
> commercial graphics interface (remember DISSPLA?). Maybe now it's different.

The soon to be released gnuplot 4.2 also has a wxWidgets terminal. I've
tried it and it looks great (anti-aliased fonts and lines). I've been
ready to give up hope for gnuplot, but this has convinced me to give it
a second chance. wxwidgets is a cross-platform toolkit that supposedly
runs natively on each supported platform, so presumably this means X11
is not required to run it on Mac or Windows.

I fail to see why this new terminal is important other than being
good-looking: even today gnuplot can run natively on X11, win32 &
Aqua. Much more important features to look for would be fine-grained
control on graph appearance. Are this available?

I haven't explored all of the options, but it does, for example, allow custom defined line styles, where the user has complete control over color, width, and other line parameters. I think by making all lines customized in this way, octave would gain complete control over line styles, making the backend for object graphics easier to implement. I think it would also eliminate the inconsistencies seen between line styles in different terminals.

I tried plplot once or twice but I finally gave up on it because it found it unstable on Linux.

With the new gnuplot release, it should not be too difficult to add
better control over line width, color, etc. It still seems like the
shortest path to a working backend to the object-graphics frontend. On
the other hand, the real weakness is that gnuplot is a standalone
program, rather than a library. The main problem I see with this is that
data is transfered via file I/O, rather than simply using on data that
is already in memory. The new version helps a little bit because binary
data transfer is now supported, but it's still suboptimal for large
amounts of data. The other big benefit of the new gnuplot is support for
images, so that the image display routines can be displayed as plots
with the axes and titles and all.

Anyway, I don't mind dumping gnuplot when something that can replace it
supports all of the necessary features, but I agree with John that for
now updating the gnuplot interface seems the quickest way to get what
people want. I'm happy to be proven wrong by the OpenGL supporters.


The way I see it, the biggest problem with using gnuplot for a backend
is that while it is a very good stand-alone graphing tool ,it is very
bad as a low level plotter (i.e. lines, patches & text).
With gnuplot you can produce very nice and good quality graphs w/o
needing octave at all. The problem starts when you try to control it:
you would have to bend over backwards in order to have gnuplot display
the graphic "document"  that octave wants to display. You can already
see this now -- while high level plots from octave look great on
gnuplot, attempts at low level manipulating are much harder -- e.g.
the automatic_replot=1 problem, multiplots, etc..

I think the new version may have dealt with some of these issues, but I don't know to what extent.


reply via email to

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