Re: Release Plans

[Rik]

On 09/30/2013 07:40 PM, Daniel J Sebald wrote:
> 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.
I find gnuplot slow in general, even when not trying to do animations.
>
>
>>  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.
There are plenty of items which are borderline bugs, but there are also
things where we simply don't have adequate control.  In legend.m, for
instance, we rely on gnuplot to place the keybox.  With OpenGL, we have all
the Matlab-compatible properties such as position, outerposition, and
tightinset.
>
>
>> 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)?
>
I think the decision was that Qt widgets would not be a gating item for
this release, and that FLTK widgets would be fine for the time being.

--Rik
> 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
>
>
>