gnuplot-beta — Developers and beta testers of new gnuplot code

Re: How do I test dll for import feature on MinGW?

[Bastian M. <bma...@we...>]

Am 11.03.2014 06:16, schrieb Tatsuro MATSUOKA:
> Hello
>
> I have build the recent cvs source (ChangeLog date 2014-03-10) on MinGW platform.
> I would like to test import dll feature.
>
> Different from cygwin build, Makefile was not made in demo/pluglin directory.
>

For the MinGW build we typically use config/mingw/Makefile, not the 
autotools (configure). The Makefile has support for building 
demo_plugin.dll. Note that you need MSYS to build.

   Bastian


> I tried cd to demo/pluglin directory and execute
>
> $ automake
> automake: `configure.ac' or `configure.in' is required
>
> I could not make Makefile.
>
> So I tried at demo/pluglin directory
>
> $ gcc -c demo_plugin.c -I../../src
> In file included from ../../src/gp_types.h:40:0,
>                   from gnuplot_plugin.h:2,
>                   from demo_plugin.c:14:
> ../../src/syscfg.h:365:23: error: two or more data types in declaration specifiers
> ../../src/syscfg.h:365:1: warning: useless type name in empty declaration [enabled by default]
>
> The error
> syscfg.h:365:23: error: two or more data types in declaration specifiers
> seems to be critical.
>
> Any suggestions ?
>
> Regards
>
> Tatsuro
>

How do I test dll for import feature on MinGW?

[Tatsuro M. <tma...@ya...>]

Hello

I have build the recent cvs source (ChangeLog date 2014-03-10) on MinGW platform.
I would like to test import dll feature.

Different from cygwin build, Makefile was not made in demo/pluglin directory.

I tried cd to demo/pluglin directory and execute

$ automake
automake: `configure.ac' or `configure.in' is required

I could not make Makefile.

So I tried at demo/pluglin directory

$ gcc -c demo_plugin.c -I../../src
In file included from ../../src/gp_types.h:40:0,
                 from gnuplot_plugin.h:2,
                 from demo_plugin.c:14:
../../src/syscfg.h:365:23: error: two or more data types in declaration specifiers
../../src/syscfg.h:365:1: warning: useless type name in empty declaration [enabled by default]

The error
syscfg.h:365:23: error: two or more data types in declaration specifiers
seems to be critical.

Any suggestions ?

Regards

Tatsuro

Re: patch: qtterminal: make point plots aware of linewidth

[sfeam <sf...@us...>]

On Friday, 07 March 2014 10:50:32 AM Dieter Ries wrote:
> Hi everybody,
> 
> this is my first contribution here, so if my form or the way to send 
> this patch is wrong, please correct me.

I have it now, but please create a tracker item on the SourceForge
patch tracker and upload it there also.   That way if I lose it I
know where to find it again.  Also people can provide feedback by
attaching comments to the tracker.

> The qt terminal did not take the linewidth parameter of a plot into 
> account, when plotting 'with points'. Especially for point types 1 and 
> 2, but in general for all non-filled point types, this results in points 
> drawn with very thin lines, which tend not to be visible well when 
> printed, for example.
> 
> Attached patches change this for gnuplot 4.6.5 and latest 4.7-CVS.
> Like on other terminals, it's now possible to plot 'with points lw 2' to 
> get the points made of thicker lines.
> 
> I am not sure, if the way I implemented this is the right way, 
> especially for the more complicated QtGnuplotPoints:: way of drawing points.

I'm not sure either.   It does seem to work as advertised, but I
don't have time right now to look deeper.

In testing your patch I suddenly realize that the qt terminal is missing
the usual option "set term qt ... linewidth N".   So probably we should
add that, at which point you patch may or may not need to multiply by an
additional value, depended on how the 'set term' part is implemented.

Thanks for the patch. 

	Ethan

 
> 
> 
> Thanks in advance for feedback on these patches.
> 
> Cheers,
> Dieter

Re: Clarification on terminal size for Qt terminal and generally

[Daniel J S. <dan...@ie...>]

On 03/09/2014 04:47 PM, Daniel J Sebald wrote:

>  I'm in the
> middle of programming this right now, so it would be good to know how it
> should behave.

I've placed an initial version Qt window size retention on the patch 
tracker:

http://sourceforge.net/p/gnuplot/patches/663/

I left the behavior of the window sizing as is for now, and there are 
still a couple bugs associated with the size retention.  However, the 
important thing is the conceptual changes, and I'd like to know if you 
think it is an improvement.

Dan

PS: One comment for anyone interested in Qt programming.  Try to avoid 
any use of dynamic_cast<>, i.e., a glorified form of casting for Qt.  If 
you think you can't avoid using that syntax, then try harder.  :-)  The 
reason is that whenever that syntax is necessary, one is almost assured 
to be programming Qt in a way that doesn't fit its paradigm and will 
prove to be a problem down the road.  One is better off approaching 
things in a different way.  With Qt it usually takes a little trial and 
error to find the best setup, but once it's found things fall in place 
pretty nicely.

Re: RFC: dashtype, aka separate control of line property descibing the dot-dash pattern

[sfeam <sf...@us...>]

On Sunday, 09 March 2014 11:49:09 PM Juhász Péter wrote:
> There was discussion about this (separating the control of line pattern
> from the linetype property) in conjunction with the upcoming major
> release. I thought a bit on it and I'd like to know if I'm on the right
> track.
> 
> So there would be a new line property "dashtype" or "dt", allowed
> everywhere a line specification is accepted.
> 
> E.g.
> 
>    set linetype 1 dashtype 2 linewidth 3
>    set linestyle 2 dashtype 4 linecolor rgb "red"
>    plot x with lines dashtype 5
> 
> This new property would of course be reported by show {linestyle|
> linetypes}, save etc., however, the output of these show commands would
> be a bit different. Currently, they are like this:
> 
>    show linetypes
> 
> 	Linetypes repeat every 0 unless explicitly defined
> 	linetype 1,  linetype 1 linecolor linewidth 3.000 pointtype 1 pointsize
> default pointinterval 0
> 
>    show linestyle
> 
> 	linestyle 2,  linetype 2 linecolor rgb "red"  linewidth 1.000 pointtype
> 2 pointsize default pointinterval 0
> 
> 
> Especially in the first case the multiple references to "linetype" is
> confusing. So with the new dashtype property introduced it would replace
> "linetype" in these reports.

Yes. This is exactly the way I see it also.

> Now for the meaning and semantics of the new property:
> Unless otherwise specified, the numeric dashtype would increase
> monotonically in subsequent plots in a single plot command, just as
> linecolor and pointtype do.

That is misleading.
The only thing that increases monotonically is the linetype.
Each linetype has a set of associated properties, so progressing from
lt 1 to lt 2  has the effect of progressing from the point type associated
with lt 1 to the point type associates with lt 2.  These are typically
different, but there is no requirement that they be different.  
It is perfectly reasonable to want all my linetypes to use pt 7
(solid circle) and be differentiated from each other only by color.

That might be what you were saying anyhow, but I thought I'd try 
stating it more clearly.

> So e.g. "plot for [i=0:10] i*x" would do exactly the same as before.
> But "plot for [i=0:10] i*x" dashtype 1 would keep the line pattern the
> same for all plotted lines while still cycling the color (as opposed to
> the current state of affairs, where "lt 1" fixes the color as well).

Sort of.  I think I would typically define all the linetypes to default
to solid, which I suppose is dt 0.   So either of those commands would
produce only solid lines.  If I wanted to increment over dash patterns
and not color (typically for monochrome plots) I would substitute a
new set of default linetypes
   set linetype 1 dt 1 lc rgb "black"
   set linetype 2 dt 2 lc rgb "black"
   set linetype 3 dt 3 lc rgb "black"
This is more or less what the existing file .../share/colors_mono.gp
does, except that it uses "dt" rather than "lt" in the definitions.

> Here we hit a snag: what do the numeric dashtypes exactly mean?
> The answer is that it depends on the terminal.
> I haven't looked at all of them but each one supports a different set of
> line patterns in a different order (if they support dashes at all).
> 
> This should be made consistent, which seems to be a large amount of work
> because the specific patterns are usually hardcoded deep into the
> terminal code (e.g. in the postscript terminal they are implemented in
> native postscript).

That is what I envision the state being for 5.0.rc1
We have defined a new syntax that distinguishes lt from dt,
but have not yet changed the set of dash patterns that are
actually available.

I then see two ways forward from there.  Well three.

1) Leave it at that.  Each terminal is different, hopefully in a way
   that makes sense for that terminal.  No worse than we have now.

2) Work through all the terminals to standardize the first N dash
   patterns.  I don't really know what N would be, 4? 8?

3) Leave the underlying terminal-specific sequence alone, but implement
   a new set of commands
     set dashtype N {n1, n2, n3, ...}  # like svg.trm SVG_dashpattern[][]
     set dashtype N "xxxx..."          # where x is ' ' or '.' or '-'
   The second one is a user-friendly version of the first, where
   the program converts internally to the first form.
   This is what I would prefer long-term.

Option 3 treats the dash patterns analogously to the v4.6 treatment of
linetypes.  The original ones are still there underneath because for at
least some terminals they are intrinsic to the terminal.  But the
"linetype" you see as a user is a defined construct that can be 
customized as you like for colors, points, etc.

> One final question: what about user-specified patterns? Are they needed
> at all? If yes, what would be the preferred syntax?
> Should there be a separate "set dashtype" command where the user could
> set explicit dash and space lengths? This would offer the most
> flexibility, but it would be hard to implement it across all terminals.

See above.  I think we are in agreement.

> Or should there be separate keywords, like "solid", "dashed", "dot-dash"
> etc?

I don't like that in the general case, but I suppose it might be
useful to accept "solid" as a synonym for "dt 1"  just as we currently
accept "bgnd" as a synonym for "lc whatever-the-background-got-set-to".
 
> (I prefer the string version, with the addition that "solid" should be
> an allowed keyword because it's a common, trivial case.)

We are clearly on the same page :-)

> Peter Juhasz

RFC: dashtype, aka separate control of line property descibing the dot-dash pattern

[Juhász P. <pet...@gm...>]

There was discussion about this (separating the control of line pattern
from the linetype property) in conjunction with the upcoming major
release. I thought a bit on it and I'd like to know if I'm on the right
track.

So there would be a new line property "dashtype" or "dt", allowed
everywhere a line specification is accepted.

E.g.

   set linetype 1 dashtype 2 linewidth 3
   set linestyle 2 dashtype 4 linecolor rgb "red"
   plot x with lines dashtype 5

This new property would of course be reported by show {linestyle|
linetypes}, save etc., however, the output of these show commands would
be a bit different. Currently, they are like this:

   show linetypes

	Linetypes repeat every 0 unless explicitly defined
	linetype 1,  linetype 1 linecolor linewidth 3.000 pointtype 1 pointsize
default pointinterval 0

   show linestyle

	linestyle 2,  linetype 2 linecolor rgb "red"  linewidth 1.000 pointtype
2 pointsize default pointinterval 0


Especially in the first case the multiple references to "linetype" is
confusing. So with the new dashtype property introduced it would replace
"linetype" in these reports.

Now for the meaning and semantics of the new property:
Unless otherwise specified, the numeric dashtype would increase
monotonically in subsequent plots in a single plot command, just as
linecolor and pointtype do.

So e.g. "plot for [i=0:10] i*x" would do exactly the same as before.
But "plot for [i=0:10] i*x" dashtype 1 would keep the line pattern the
same for all plotted lines while still cycling the color (as opposed to
the current state of affairs, where "lt 1" fixes the color as well).

Here we hit a snag: what do the numeric dashtypes exactly mean?
The answer is that it depends on the terminal.
I haven't looked at all of them but each one supports a different set of
line patterns in a different order (if they support dashes at all).

This should be made consistent, which seems to be a large amount of work
because the specific patterns are usually hardcoded deep into the
terminal code (e.g. in the postscript terminal they are implemented in
native postscript).


One final question: what about user-specified patterns? Are they needed
at all? If yes, what would be the preferred syntax?

Should there be a separate "set dashtype" command where the user could
set explicit dash and space lengths? This would offer the most
flexibility, but it would be hard to implement it across all terminals.

Or should the pattern be specified with strings like "--...",
interpreted in a do-what-I-mean sense?

Or should there be separate keywords, like "solid", "dashed", "dot-dash"
etc?

(I prefer the string version, with the addition that "solid" should be
an allowed keyword because it's a common, trivial case.)

Peter Juhasz

Re: Clarification on terminal size for Qt terminal and generally

[Daniel J S. <dan...@ie...>]

On 03/09/2014 04:47 PM, Daniel J Sebald wrote:
> On 03/09/2014 04:07 PM, Jérôme Lodewyck wrote:

>> The code of the qt terminal as it is written now, assumes the
>> opposite: the
>> size set by the "size" option of the "set term qt" command is the size
>> of the
>> plotting area (more precisely of the viewport widget of the QGraphicsView
>> showing the plot), and the application that embeds the plot area,
>> which can be
>> (but not necessarily is) a QtGnuplotWindow, takes care of reserving more
>> screen space to fit other widgets, such as a toolbar, a title bar...
>
> OK, what you describe is what I originally understood from the Qt
> documentation. Again, I'm not sure that is what it is supposed to be.

By the way, x11 window retains the plot dimensions when type 'm' to 
add/remove the status bar.  That behavior isn't the same as Qt.

Dan

Re: Clarification on terminal size for Qt terminal and generally

[Daniel J S. <dan...@ie...>]

On 03/09/2014 04:07 PM, Jérôme Lodewyck wrote:
> The bottom line is that setting a custom size for a widget with Qt is no less
> than a nightmare. Apparently, there is no way to tell Qt that the widget
> should have a given size to start with, and then be resizable. So I have spend
> countless hours trying to find tweaks to emulate this behaviour, as until now
> all my attempts have resulted in an incorrect behaviour for at least one Qt
> version on one platform. I would be very happy if you come up with code that
> works correctly, but this task is not easy because this code has to be tested
> on the 3 platforms (Unix, OSX, windows) which have different sizing policy for
> widgets, and with Qt 4 and Qt 5.

I think there are ways to control this in Qt utilizing the QLayout 
family of objects.  A QLayout is a container class and one adds widgets 
and then lets Qt do the work.

http://qt-project.org/doc/qt-4.8/layout.html

(You've used this so I'm sure you are aware of it.)  I think the QLayout 
can be placed in different modes (e.g., how to handle stretch), use 
QSpace to put space between widgets if desired, etc.  It's just a matter 
of finding the right combination of settings and groupings.

But it looks to me that for the Qt gnuplot_qt window it is pretty much 
the QMainWindow with only one widget--the plot area (or view port), and 
that plot area is what is the mandatory central widget.  The status bar 
and menus are all standard parts of the QMainWindow.  Since QMainWindow 
has a layout which can be set, I have to think that QMainWindow will 
figure out the dimensions for that central widget.  It's what is left 
over from all the other items on the QMainWindow.  (Or perhaps there is 
some way of making the size of the central widget immutable so that Qt 
has to resize the QMainWindow in order to fit around the central widget. 
  I'm not sure.)


>> I'm beginning to suspect that is the case, and what is different between
>> the Qt versions is probably the obscure size hint.  Newer versions are
>> probably more accurate.  However, I'm wondering if we can get away from
>> the size hint and get direct results with just a little clean up of
>
> The size hint tweak is a very recent addition that is used to set the size of
> the window before it is displayed. Before this addition, the window was
> resized after it is display, and sometimes was stuck in a wrong size.

I think that can be fixed.


>> Now, from what Ethan describes, the size specifications option for qt
>> terminal refers to the outer dimensions of the QMainWindow, not the
>> plotting area.  I think the documentation could be clearer on this:
>
> I was not aware of this interpretation of the specification, but it looks weird
> to me. Setting the size of the window would mean that the size of the plotting
> area would depend, for instance, on whether the toolbar is hidden or not, on
> the window decoration for the title bar...

Let's confirm this with Ethan and others.  But I think that is the 
behavior.  If one tears a dockable item off of the QMainWindow it opens 
up space and the plot can be made bigger.  The alternate would be to 
shrink the main window.  It could be programmed either way.  I'm in the 
middle of programming this right now, so it would be good to know how it 
should behave.


> Also, don't forget that the QtGnuplotWidget can also be used without a
> QtGnuplotwindow around it. it can be embedded in any Qt application, in which
> case I don't know what size the widget should actually report to the gnuplot
> core if the size the widget usually reports is the total window size.

Yes, that is true.  I see that is how qt_graphics() is programmed right 
now.  In the case of an external widget, I suppose it is easy; just 
inquire what the window size is for the widget.  Any size specifications 
don't apply when there is an external widget.  The external Qt window is 
more analogous to the viewport but perhaps not necessarily the 
gnuplot_qt window.


>>    "The size of the plot area is given in pixels, it defaults to 640x480.
>>    In addition to that, the actual size of the window also includes the space
>> reserved for the toolbar and the status bar."
>>
>> The 640x480 is not the plot area, more accurately the "size of the
>> window".  Is there consensus on this?
>>
>
>   The code of the qt terminal as it is written now, assumes the opposite: the
> size set by the "size" option of the "set term qt" command is the size of the
> plotting area (more precisely of the viewport widget of the QGraphicsView
> showing the plot), and the application that embeds the plot area, which can be
> (but not necessarily is) a QtGnuplotWindow, takes care of reserving more
> screen space to fit other widgets, such as a toolbar, a title bar...

OK, what you describe is what I originally understood from the Qt 
documentation.  Again, I'm not sure that is what it is supposed to be.

Dan

09-Mar-2014 Update on version 5 progress

[sfeam <sf...@us...>]

I made a list of proposed targets for version 5 based on recent discussion.
Let me know if I missed any.

The first column indicates current status (09-Mar-2014)
* = complete
+ = preliminary version
- = proposed

Already in CVS
================================================================
* Default to enhanced text mode
* Support for an arbitrary number of axes
+ new "fit" code (in progress)

Target for release candidate 5.0.rc1
================================================================
+ Bold/Italic markup in enhanced text mode (in progress)
- Change the default color sequence, if only so that users know
  this is possible to customize
- Smarter auto-layout of multiplots (e.g. patch #611)
- bit-shift operators  C = A << n    C = A >> n

Target for release 5.0, may be incomplete in rc1
================================================================
- separate control of line property descibing the dot-dash pattern
  e.g. set linetype N dashtype 3 linecolor rgb "blue" 
+ confirm consistency of first N point types across all terminals
  N is I think currently 8.  Increase to 12 or 16?

Unrealistic for version 5; Defer to version 6
================================================================
- multi-language support layer (Patchset #436)
- refactor main data input loop in graphics.c / datafile.c
- refactor log-scale code (store original data, scale during output)

Needs more discussion
================================================================
- Jon Gjengset mentioned a problem with image mode that I am not
  familiar with and doesn't seem to have a Bug Tracker entry.
  "Visible pixel grid has a scan line longer than previous scan lines"
  Is this just a bug, or is there something more fundamental that
  might change the image syntax or handling?
- Should we switch to 64-bit integers everywhere?
  I really don't know how much work this would be.
  This would have the side effect of solving problems with storing
  32-bit ARGB color values in an int.
- Should use of ARGB colors require a new keyword?
  e.g. linecolor {rgb 0xRRGGBB | rgba 0xAARRGGBB}
  My personal opinion is no, but Tait has argued yes.
  More opinions please?
- Do we need additional explicit type-conversion operators?
  e.g.  A=5; string(A)   yields "5"

Feature Request (doesn't need to be coordinated with version 5)
================================================================
- various key options (#183, #297, #339, multiple keys) 
- arrays
- combining data from multiple files into single using spec
- error reports should indicate original source line prior to
  merging continuation lines

Re: Clarification on terminal size for Qt terminal and generally

[Jérôme L. <lod...@us...>]

The bottom line is that setting a custom size for a widget with Qt is no less 
than a nightmare. Apparently, there is no way to tell Qt that the widget 
should have a given size to start with, and then be resizable. So I have spend 
countless hours trying to find tweaks to emulate this behaviour, as until now 
all my attempts have resulted in an incorrect behaviour for at least one Qt 
version on one platform. I would be very happy if you come up with code that 
works correctly, but this task is not easy because this code has to be tested 
on the 3 platforms (Unix, OSX, windows) which have different sizing policy for 
widgets, and with Qt 4 and Qt 5.

> I'm beginning to suspect that is the case, and what is different between
> the Qt versions is probably the obscure size hint.  Newer versions are
> probably more accurate.  However, I'm wondering if we can get away from
> the size hint and get direct results with just a little clean up of

The size hint tweak is a very recent addition that is used to set the size of 
the window before it is displayed. Before this addition, the window was 
resized after it is display, and sometimes was stuck in a wrong size.
 
> Now, from what Ethan describes, the size specifications option for qt
> terminal refers to the outer dimensions of the QMainWindow, not the
> plotting area.  I think the documentation could be clearer on this:

I was not aware of this interpretation of the specification, but it looks weird 
to me. Setting the size of the window would mean that the size of the plotting 
area would depend, for instance, on whether the toolbar is hidden or not, on 
the window decoration for the title bar...
Also, don't forget that the QtGnuplotWidget can also be used without a 
QtGnuplotwindow around it. it can be embedded in any Qt application, in which 
case I don't know what size the widget should actually report to the gnuplot 
core if the size the widget usually reports is the total window size.

>   "The size of the plot area is given in pixels, it defaults to 640x480.
>   In addition to that, the actual size of the window also includes the space
> reserved for the toolbar and the status bar."
> 
> The 640x480 is not the plot area, more accurately the "size of the
> window".  Is there consensus on this?
> 

 The code of the qt terminal as it is written now, assumes the opposite: the 
size set by the "size" option of the "set term qt" command is the size of the 
plotting area (more precisely of the viewport widget of the QGraphicsView 
showing the plot), and the application that embeds the plot area, which can be 
(but not necessarily is) a QtGnuplotWindow, takes care of reserving more 
screen space to fit other widgets, such as a toolbar, a title bar...
 
> If there is, then here is another question.  What do
> 
> term->xmax
> term->ymax
> 
> represent to the core code?  Outer window dimensions?  Or the plot area?

They are set to qt_oversampling multiplied by the plot  area dimensions.
 
Jérôme

Re: X11_ymax_saved artifact in x11.trm... not

[Dima K. <gn...@di...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[sfeam <sf...@us...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[Dima K. <gn...@di...>]

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

Re: Plans for gnuplot version 5

[sfeam <sf...@us...>]

On Thursday, 06 March 2014 07:57:16 AM pl...@pi... wrote:
> 
> Obviously, text extent is the other big inconsistency between terminals. 
> If easing of the strict BC policy ( which is excellent BTW ) for the 
> jump to v5 allows something to be done about text extent, that would be 
> a MAJOR improvement.
> 
> /Peter

Explain please.  What do you mean "text extent"?

	Ethan

Re: X11_ymax_saved artifact in x11.trm... not

[Juhász P. <pet...@gm...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[Daniel J S. <dan...@ie...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[Juhász P. <pet...@gm...>]

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

Clarification on terminal size for Qt terminal and generally

[Daniel J S. <dan...@ie...>]

Jérôme,

I've been looking at the Qt terminal code to address sizing retention. 
Through some dialog for patch #661 Ethan and I began to question the 
differences between Qt versions and how that would effect an initial 
incorrect plot size that I and apparently Mojca are seeing.

I'm beginning to suspect that is the case, and what is different between 
the Qt versions is probably the obscure size hint.  Newer versions are 
probably more accurate.  However, I'm wondering if we can get away from 
the size hint and get direct results with just a little clean up of

QtGnuplotWidget::processEvent()

The gist of it is that QtGnuplotWidget is made to be the central widget 
of the QMainWindow, so I would guess just doing that alone is enough to 
impart size adjustment on QtGnuplotWidget without having to process 
GESetWedgetSize inised processEvent.  But before addressing that, I'd 
like to clear up the layout of the widgets in the main window.

Now, from what Ethan describes, the size specifications option for qt 
terminal refers to the outer dimensions of the QMainWindow, not the 
plotting area.  I think the documentation could be clearer on this:

  "The size of the plot area is given in pixels, it defaults to 640x480.
  In addition to that, the actual size of the window also includes the space
  reserved for the toolbar and the status bar."

The 640x480 is not the plot area, more accurately the "size of the 
window".  Is there consensus on this?

If there is, then here is another question.  What do

term->xmax
term->ymax

represent to the core code?  Outer window dimensions?  Or the plot area?

I ask because if it is the latter, then

	// Set plot size
	if (qt_setSize)
	{
		term->xmax = qt_oversampling*qt_setWidth;
		term->ymax = qt_oversampling*qt_setHeight;
		qt_setSize = false;
	}

seems questionable.  If the latter, then really the size should be sent 
to gnuplot_qt, which then computes the plotting area size and sends that 
info back to the inboard driver, which eventually ends up in term->xmax, 
term->ymax.

Let's clarify these things and then proceed to do a little bit of 
cleanup of the code.

Dan

Re: X11_ymax_saved artifact in x11.trm... not

[<pl...@pi...>]

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.

Re: X11_ymax_saved artifact in x11.trm... not

[Daniel J S. <dan...@ie...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[sfeam <sf...@us...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[Dima K. <gn...@di...>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[Ethan M. <merritt@u.washington.edu>]

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

Re: X11_ymax_saved artifact in x11.trm... not

[Daniel J S. <dan...@ie...>]

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

X11_ymax_saved artifact in x11.trm... not

[Daniel J S. <dan...@ie...>]

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