Re: Octave-maintainers Digest, Vol 38, Issue 56

[Ben Abbott]

On May 31, 2009, at 2:58 PM, Daniel J Sebald wrote:

> Rik wrote:
> > > ------------------------------------------------------------------------
> > >
> > > Subject:
> > > Re: plot and image demos (growing window)
> > > From:
> > > Ben Abbott <address@hidden>
> > > Date:
> > > Sat, 30 May 2009 03:13:39 -0400
> > > To:
> > > Rik <address@hidden>
> > >
> > > To:
> > > Rik <address@hidden>
> > > CC:
> > > address@hidden
> > >
> > >
> > >
> > >
> > >
> > > Thanks Rik. The only difference I see in the two files are in the  
> > > beginning.
> > >
> > >
> > >
> > > From 9097
> > >
> > >
> > >
> > >
> > > > set terminal x11 enhanced title "Figure 1" ; set output "/dev/ 
> > > > null";
> > > > reset; set autoscale fix;
> > >
> > >
> > >
> > >
> > > From the current tip
> > >
> > >
> > >
> > >
> > > > set terminal x11 enhanced title "Figure 1" set output '/dev/null';
> > > > reset; set autoscale keepfix;
> > >
> > >
> > > The "output" is not relevant as it is not present when rendered to  
> > > the screen.
> > >
> > >
> > >
> > > However, when add both the remaining differences to the current  
> > > sources the window still grows.
> > >
> > >
> > >
> > > Rik, can you confirm that your build for 9097 did *not* produce a  
> > > growing window when running a gnuplot 4.2.5 or 4.3.0?
> > The problem definitely seems to be gnuplot related.  For gnuplot  
> > version
> > 4.2.2, revision 9097 works.  For gnuplot version 4.2.5, revision 9097
> > fails.  4.3 won't compile on my Hardy Heron box.  I suppose we  
> > could try
> > to work-around their bug if we could figure out how we are  
> > triggering it
> > or we will simply have to let it pass as being outside of Octave.
>
> I'm not saying there isn't a bug in gnuplot, but I'm still trying to  
> understand what the method is for controlling the size of the x11  
> window and/or mouse.  (Unfortunately, savanah server isn't working  
> so that I can view the latest code.)
>
> There is too much in between Octave and gnuplot to conclude this is  
> a gnuplot bug based on your observation.  For example, I see in the  
> gnuplot record the following changes:
>
> Revision 1.160.2.11 - (view) (download) (annotate) - [select for  
> diffs]
> Thu Dec 25 05:50:59 2008 UTC (5 months ago) by sfeam
> Branch: branch-4-2-stable
> Changes since 1.160.2.10: +80 -2 lines
> Diff to previous 1.160.2.10 , to branch point 1.160
>
> set term x11 {size XX,YY} {position XX,YY}
>
> Revision 1.179 - (view) (download) (annotate) - [select for diffs]
> Thu Dec 25 03:02:05 2008 UTC (5 months ago) by sfeam
> Branch: MAIN
> Changes since 1.178: +80 -2 lines
> Diff to previous 1.178
>
> set term x11 {size XX,YY} {position XX,YY}
>
> So, if this is when the new feature was added, it could simply be  
> that this is when the bug started appearing.  That is, before the  
> above dates, gnuplot didn't have the feature that Octave is  
> attempting to use so there is no way the hypothetical bug could have  
> been illustrated whether the source of the problem is in Octave or  
> gnuplot.  Restating, perhaps the bug in Octave didn't appear until  
> gnuplot has the option {size XX,YY} and {position XX,YY}.

Presently this size/position information is only sent to x11 *once*  
for each window, when it is first created.

> Ben, are you sure that Octave doesn't currently have the feedback  
> path of getting the X11 window size from X11 resources?  I see in  
> gnuplot_drawnow.m the method
>
> screensize    = get (0, "screensize")(3:4);
>
> used in computing the size.  Furthermore, I see in some of the C++  
> code that John added something that gets screensize from the X11  
> window system:
>
> 2009-01-22  John W. Eaton  <address@hidden>
>
>         * toplev.cc (octave_config_info): Check OCTAVEUSE_OS_X_API instead
>         of __APPLE__ && __MACH__.
>
>         * display.cc (display_info::init): Get info for Windows and OS X
>         systems.

The screensize is not the same thing as the figure size. For me, my  
computer's sceen size is 1440x878 pixels.

> So I'm wondering if there is in fact a feedback loop where
>
> 1) Octave tells gnuplot to set size of the window.
> 2) gnuplot does so, but then also tags an extra 13 pixels for the  
> coordinates line
> 3) Octave inquires the screen size from X11 resources, so the actual  
> size is 13 larger than what Octave last requested.
> 4) repeat beginning at line 1.

No. This is not in the code.

> *If* that is the case, the solution is to unset the mouse before  
> inquiring about the X11 screensize, or subtract off 13 points if the  
> mouse is known to be active, or lobby Ethan at the gnuplot  
> discussion list to not increase the size of the plot for the  
> coordinate line at the bottom of the figure, but instead subtract  
> from the available plotting space (or have an option to configure  
> how that line behaves).
>
> The one thing I'm uncomfortable with in the first two solutions  
> above is that the coordinate line in the plot window doesn't appear  
> immediately after a "set mouse" until the mouse is moved over the  
> screen.  (But hopefully gnuplot developers would fix that easily  
> enough if asked.)
>
> Dan
>
>
> PS: Does this bit of code in gnuplot_drawnow do anything if we end  
> up using {size XX,YY} option?
>
>     if (any (strncmpi (term, {"x11", "wxt"}, 3)) && new_stream
>           && __gnuplot_has_feature__ ("x11_figure_position"))
>       ## The "close" is added to allow the figure position property
>       ## to remain active.
>       term_str = sprintf ("%s close", term_str);
>     endif

This code is responsible for sending the terminal command to gnuplot.  
Notice it is only sent if the plot stream is a "new_stream". Thus, it  
only gets sent one time for each window.

Ben