|
From: | Daniel J Sebald |
Subject: | Re: Release Plans |
Date: | Mon, 30 Sep 2013 21:40:29 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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 gnuplotlicense 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
[Prev in Thread] | Current Thread | [Next in Thread] |