Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 00:31:38
|
At first I thought there was some kind of artifact in the x11.trm code
regarding X11_ymax_saved, and the following related snippets:
/* Dima Kogan Sep 2012: Above is true when generating the plot THE
FIRST
TIME. I now save the sizing information every time the window sizes
change (in the ..._saved variables). Thus I no longer need
to ask for this information NOW, and can just use it.
*/
if (X11_ymax_saved > 0.0) { /* use saved sizes if they're valid */
term->h_char = X11_hchar_saved;
term->v_char = X11_vchar_saved;
term->h_tic = term->v_tic = X11_vchar_saved / 2.5;
term->ymax = X11_ymax_saved;
}
/* Cached sizing values for the x11 terminal.
* Updated/Maintained in mouse.c
*/
int X11_hchar_saved, X11_vchar_saved;
double X11_ymax_saved = -1.0;
Nowhere in x11.trm is X11_ymax_saved set anywhere. But then I saw in
mouse.c the following:
/* EAM FIXME: Despite the name, only X11 uses this to pass font info. */
/* Everyone else passes just the plot height and width. */
if (!strcmp(term->name,"x11")) {
/* These are declared in ../term/x11.trm */
extern int X11_hchar_saved, X11_vchar_saved;
extern double X11_ymax_saved;
/* Cached...
This is a very good example of the code quality issues that Péter
pointed out. Here is a core-level file (mouse.c) that is going to a
terminal file to modify some global variables via "extern". These kinds
of caching things should be kept local to the specific terminal.
[I wonder why
X11_ymax_saved = (double)term->xmax * (double)ge->my /
fabs((double)ge->mx);
is being done in response to a GE_fontprops command. Is GE_fontprops
somehow guaranteed to happen if the user uses the mouse to resize the
X11 window? I then ask if caching the window size actually saves
anything if this code in do_event() is being accessed more than
X11_graphics() is, which in both cases might not be all that often.]
Furthermore, the mouse.c routine is do_event() which is what I called
into question a little over a week ago. Was it the Qt terminal that was
calling this do_event routine directly in a recursive way? And it
seemed to me that Qt terminal didn't really need to do so because the
information it was using was already available to the core code.
I don't think it is worth fixing right now, but grepping for "ifdef X11"
shows up 20 times in a few core files. It would be nice to disentangle
that terminal from the main code.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 00:37:14
|
On 03/08/2014 06:31 PM, Daniel J Sebald wrote: > [I wonder why > > X11_ymax_saved = (double)term->xmax * (double)ge->my / > fabs((double)ge->mx); > > is being done in response to a GE_fontprops command. Is GE_fontprops > somehow guaranteed to happen if the user uses the mouse to resize the > X11 window? I then ask if caching the window size actually saves > anything if this code in do_event() is being accessed more than > X11_graphics() is, which in both cases might not be all that often.] In fact, this window size caching has a bug, depending upon perspective. Try the following: gnuplot> set term x11 1 Terminal type set to 'x11' Options are '1 nopersist enhanced' gnuplot> plot x [shrink the window size using the mouse to something small] gnuplot> set term x11 2 Terminal type set to 'x11' Options are '2 nopersist enhanced' gnuplot> plot x**2 The second window is created with small size when perhaps it should be the default window size. Is that what should happen? If not, somewhere in the options code should be something that changes the cached value back to the default window size. That, or perhaps remove caching if it doesn't amount to very much. Right now is it a mix of mouse driven changes to term->xmax and query requests for xmax and ymax? Let me know how you think this should be fixed and I will change the Qt terminal in the same way as I'm trying to address the Qt size retention issue right now. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2014-03-09 01:00:08
|
I suggest not to use the x11 terminal as a model for anything at all. It has fallen way behind the other interactive terminals. The resizing code you point to was added largely to fix the long-standing problem that you could not control the aspect ratio of plots displayed in x11. If it has undesired side effects, that's a bug. Ethan On Saturday, 08 March 2014 06:37:03 PM Daniel J Sebald wrote: > On 03/08/2014 06:31 PM, Daniel J Sebald wrote: > > > [I wonder why > > > > X11_ymax_saved = (double)term->xmax * (double)ge->my / > > fabs((double)ge->mx); > > > > is being done in response to a GE_fontprops command. Is GE_fontprops > > somehow guaranteed to happen if the user uses the mouse to resize the > > X11 window? I then ask if caching the window size actually saves > > anything if this code in do_event() is being accessed more than > > X11_graphics() is, which in both cases might not be all that often.] > > In fact, this window size caching has a bug, depending upon perspective. > Try the following: > > gnuplot> set term x11 1 > Terminal type set to 'x11' > Options are '1 nopersist enhanced' > gnuplot> plot x > [shrink the window size using the mouse to something small] > gnuplot> set term x11 2 > Terminal type set to 'x11' > Options are '2 nopersist enhanced' > gnuplot> plot x**2 > > The second window is created with small size when perhaps it should be > the default window size. Is that what should happen? If not, somewhere > in the options code should be something that changes the cached value > back to the default window size. That, or perhaps remove caching if it > doesn't amount to very much. Right now is it a mix of mouse driven > changes to term->xmax and query requests for xmax and ymax? > > Let me know how you think this should be fixed and I will change the Qt > terminal in the same way as I'm trying to address the Qt size retention > issue right now. > > Dan |
|
From: Dima K. <gn...@di...> - 2014-03-09 01:47:11
|
Ethan Merritt <merritt@u.washington.edu> writes: > I suggest not to use the x11 terminal as a model for anything at all. > It has fallen way behind the other interactive terminals. > > The resizing code you point to was added largely to fix the > long-standing problem that you could not control the aspect > ratio of plots displayed in x11. If it has undesired side > effects, that's a bug. Right. I wrote the code in question. The x11 terminal was clearly the main graphical terminal at one point, and it's still entangled into the gnuplot core as a result. It was convoluted before I touched it, and it's now even a bit more convoluted, sadly. Before my patches, the aspect ratio control wasn't working, and fixing this was the main purpose. It didn't make sense to clean it up because this terminal is deprecated, so I added the extra logic without rearchitecting the whole thing. The main reason I care about the x11 terminal is that it was by far the fastest of the graphical renderers when I last checked (maybe a year ago). If you can speed up the qt or wxt terminals then the only reason remaining to use x11 would go away. dima |
|
From: <pl...@pi...> - 2014-03-09 08:26:01
|
On 03/09/14 03:10, Daniel J Sebald wrote: > I wouldn't classify X11 terminal as deprecated. It serves a much wider > base than several of the other terminals still retained. > > Dan I would agree. Though I enjoy working with wxt terminal, personally, a more direct rendering without yet another layer of abstraction, processing and package dependencies is sometimes valuable. Writing it off as deprecated is probably premature. /Peter. |
|
From: sfeam <sf...@us...> - 2014-03-09 02:00:24
|
On Saturday, 08 March 2014 05:47:02 PM Dima Kogan wrote: > The main reason I care about the x11 terminal is that it was by far the > fastest of the graphical renderers when I last checked (maybe a year > ago). If you can speed up the qt or wxt terminals then the only reason > remaining to use x11 would go away. > > dima Qt is now considerably faster than x11 even if you turn on all the bells and whistles (transparency, anti-aliasing) that x11 can't handle anyhow. See the other long-running thread "reworked qt terminal is much faster". Here is a copy of one of the benchmarks: 3D rotation speed (animate.dem modified to use 'set pm3d hidden3d interpolate 3,3') --------------------------------------------- 4.7 qt (old) 0.352u 0.077s 0:05.61 7.4% 4.7 x11 0.502u 0.328s 0:04.70 17.4% 4.7 wxt 2.075u 0.308s 0:02.45 96.7% 4.7 qt (new) 0.347u 0.090s 0:01.41 30.4% ---------------------------------------------- Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 02:10:43
|
On 03/08/2014 08:00 PM, sfeam wrote: > On Saturday, 08 March 2014 05:47:02 PM Dima Kogan wrote: > >> The main reason I care about the x11 terminal is that it was by far the >> fastest of the graphical renderers when I last checked (maybe a year >> ago). If you can speed up the qt or wxt terminals then the only reason >> remaining to use x11 would go away. >> >> dima > > > Qt is now considerably faster than x11 even if you turn on all > the bells and whistles (transparency, anti-aliasing) > that x11 can't handle anyhow. > > See the other long-running thread "reworked qt terminal is much faster". > Here is a copy of one of the benchmarks: > > 3D rotation speed > (animate.dem modified to use 'set pm3d hidden3d interpolate 3,3') > --------------------------------------------- > 4.7 qt (old) 0.352u 0.077s 0:05.61 7.4% > 4.7 x11 0.502u 0.328s 0:04.70 17.4% > 4.7 wxt 2.075u 0.308s 0:02.45 96.7% > 4.7 qt (new) 0.347u 0.090s 0:01.41 30.4% > ---------------------------------------------- I haven't done any formal tests, but last week when running the 'all.dem' X11 terminal still seemed noticeably faster than Qt terminal. But it's an apples and oranges comparison really. I can tell that imaging is pretty slow in Qt, but Qt is doing more. I wouldn't classify X11 terminal as deprecated. It serves a much wider base than several of the other terminals still retained. Dan |
|
From: Juhász P. <pet...@gm...> - 2014-03-09 12:23:46
|
On Sun, 2014-03-09 at 08:07 +0100, pl...@pi... wrote: > On 03/09/14 03:10, Daniel J Sebald wrote: > > I wouldn't classify X11 terminal as deprecated. It serves a much wider > > base than several of the other terminals still retained. > > > > Dan > > I would agree. Though I enjoy working with wxt terminal, personally, a > more direct rendering without yet another layer of abstraction, > processing and package dependencies is sometimes valuable. > > Writing it off as deprecated is probably premature. > > /Peter. To reinforce this last point: There are places (servers, offline machines for special purposes like industrial control etc.) where installing all the dependencies of the newer interactive terminals is hard or not possible at all. For these situations, it's good to still have an option to work interactively with a terminal that depends on X and little else. That said, I can confirm that the Qt terminal now feels about as fast as the X11 one, while being much more comfortable and prettier. Peter |
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 15:28:09
|
On 03/09/2014 07:23 AM, Juhász Péter wrote: > To reinforce this last point: > There are places (servers, offline machines for special purposes like > industrial control etc.) where installing all the dependencies of the > newer interactive terminals is hard or not possible at all. For these > situations, it's good to still have an option to work interactively with > a terminal that depends on X and little else. > > That said, I can confirm that the Qt terminal now feels about as fast as > the X11 one, while being much more comfortable and prettier. > > Peter Péter, what version of Qt are you using? I'm not experiencing this grand boost in Qt efficiency with version 4.7.4 that everyone is talking about. Dan |
|
From: Juhász P. <pet...@gm...> - 2014-03-09 17:21:42
|
On Sun, 2014-03-09 at 10:27 -0500, Daniel J Sebald wrote: > On 03/09/2014 07:23 AM, Juhász Péter wrote: > > > To reinforce this last point: > > There are places (servers, offline machines for special purposes like > > industrial control etc.) where installing all the dependencies of the > > newer interactive terminals is hard or not possible at all. For these > > situations, it's good to still have an option to work interactively with > > a terminal that depends on X and little else. > > > > That said, I can confirm that the Qt terminal now feels about as fast as > > the X11 one, while being much more comfortable and prettier. > > > > Peter > > Péter, what version of Qt are you using? I'm not experiencing this > grand boost in Qt efficiency with version 4.7.4 that everyone is talking > about. > > Dan 4.8.1, on an Ubuntu 12.04 64 bit system. I doubt it depends on Qt version differences, though: I experienced the same speedup on my work machine, which uses Centos, with a different version of Qt (I don't have access to it right now to tell which one exactly). But the speedup, at least subjectively, can indeed be described as grand: for a gnuplot version from last November it took 30 seconds or so to plot a file with ~70k lines, whereas it takes less than 2 with the current CVS head. I know that one anecdote does not make data, but for me the performance boost looks solid and real. Peter |
|
From: Dima K. <gn...@di...> - 2014-03-09 20:09:05
|
Daniel J Sebald <dan...@ie...> writes: > Péter, what version of Qt are you using? I'm not experiencing this > grand boost in Qt efficiency with version 4.7.4 that everyone is talking > about. I just tried with QT5.2, and line plots do feel very quick now. For image plots I still see that x11 is noticeably faster. Note that I didn't run any quantitative tests. Those are just eyeballed results. dima |
|
From: sfeam <sf...@us...> - 2014-03-09 20:48:11
|
On Sunday, 09 March 2014 01:08:57 PM Dima Kogan wrote: > > Daniel J Sebald <dan...@ie...> writes: > > > Péter, what version of Qt are you using? I'm not experiencing this > > grand boost in Qt efficiency with version 4.7.4 that everyone is talking > > about. > > I just tried with QT5.2, and line plots do feel very quick now. For > image plots I still see that x11 is noticeably faster. Note that I > didn't run any quantitative tests. Those are just eyeballed results. Try setting environmental variable QT_GRAPHICSSYSTEM to raster. setenv QT_GRAPHICSSYSTEM raster export QT_GRAPHCSSYSTEM=raster On my systems version 5 seems to default to this, but the documentation still says otherwise so I don't know if it's really a version difference or whether the distro packagers tweaked the default. Ethan |
|
From: Dima K. <gn...@di...> - 2014-03-09 20:53:47
|
sfeam <sf...@us...> writes: > On Sunday, 09 March 2014 01:08:57 PM Dima Kogan wrote: >> >> Daniel J Sebald <dan...@ie...> writes: >> >> > Péter, what version of Qt are you using? I'm not experiencing this >> > grand boost in Qt efficiency with version 4.7.4 that everyone is talking >> > about. >> >> I just tried with QT5.2, and line plots do feel very quick now. For >> image plots I still see that x11 is noticeably faster. Note that I >> didn't run any quantitative tests. Those are just eyeballed results. > > Try setting environmental variable QT_GRAPHICSSYSTEM to raster. > setenv QT_GRAPHICSSYSTEM raster > export QT_GRAPHCSSYSTEM=raster I just tried it with this option, and it feels about the same (i.e. rendering large images is faster with x11 than qt). I also discovered a bug in the qt terminal I'm about to report in the tracker... |
