Re: Release Plans

[Daniel J Sebald]

On 09/29/2013 02:29 PM, Rik wrote:
> On 09/29/2013 10:03 AM, Daniel J Sebald wrote:
> >  On 09/26/2013 01:54 PM, John W. Eaton wrote:
> > > On 09/26/2013 02:51 PM, Michael D. Godfrey wrote:
> > >
> > >> Now, what about the default graphics_toolkit? The GUI seems
> > >> fine with fltk. Should this be the default? I know that there are
> > >> arguments on both sides. In my case I now always use fltk.
> > >
> > > I'm OK with making OpenGL+FLTK the default:
> > >
> > > http://hg.savannah.gnu.org/hgweb/octave/rev/55680de6a897
> > >
> > > jwe
> >
> >  I'm not clear on what is gained by OpenGL+FLTK. If it is a gnuplot
> license issue, the license is pretty open, it's just that it predates
> the modern open source licenses and is too much trouble to go back and
> get approval to modify. At least, that is my understanding of it. It's
> seems like hegemony for it to not be an approved license.
> >
> There are definite advantages to using OpenGL rather than gnuplot for
> plotting. We communicate with gnuplot at arm's length over a pipe. This
> is both 1) slow, and 2) limits our ability to tweak things exactly as we
> please. There are at least 2 bug reports on the performance of the
> interface.

I'm not familiar with the bug reports, but I wonder if it is expecting 
too much at this stage if the desire is realtime graphics.  Simple 
simulations seem fast enough.  But if we are talking optimized graphics 
routines, etc. that's something that takes a full time effort.


>  Just for ballpark figures, I ran this benchmark of comet
> which repeatedly draws
>
> graphics_toolkit gnuplot;
> t = 0:.1:2*pi;
> x = cos (2*t) .* (cos (t).^2);
> y = sin (2*t) .* (sin (t).^2);
> tic; comet (x,y, 0); toc
> Elapsed time is 3.4761 seconds.
> close all hidden
> graphics_toolkit fltk
> tic; comet (x,y, 0); toc
> Elapsed time is 1.2542 seconds.
>
> So, the OpenGL interface is roughly 3X faster.

A long time ago I looked at speed issues.  From what I remember, the 
pipe was a bit slower than saving data to files.  John wanted to stay 
with a pipe.  I don't know why the pipe is slower.  To me it seems it 
should be inherently faster, but I haven't time to look into it.


> As for the other, we are not able to get complete control of the plots
> we make with gnuplot. I find all sorts of notes throughout the code
> about hacks done to try and compensate. It also splits our limited
> developer time. If we had only one plotting platform to support it would
> help.

If it is something about bugs, the gnuplot developers are pretty 
responsive to bugs.  New features is more challenging because as with 
Octave and even more so with gnuplot, time is limited.

And there is a trade off here.  Building a plotting resource from the 
ground up isn't easy.


> As for visual issues, I think the plan is to unify behind Qt widgets so
> that the GUI and the plotting appear to belong to the same application.

That's not FLTK.  What's the roadmap for Qt widgets (rhetorical question)?

It feels to me that gnuplot/FLTK is pretty much a draw, all things 
considered, but the one thing gnuplot has as pertains to the upcoming 
GUI release is that it has a Qt terminal which looks well integrated 
with the GUI.  Are most bundles compiling gnuplot with Qt terminal?  I'm 
not sure (as pointed out before with the change from Gnome 2 to Gnome 3 
I decided to take a break from the upgrading routine).  If that is an 
issue, I still think it would be wise to make it clear to users that 
Octave GUI is Qt-based and there is a gnuplot Qt terminal to match.

Dan