bugGNU Octave - Bugs: bug #39988, standard height of figures changes

 
 

bug #39988: standard height of figures changes

Submitter:  Muhali <muhali>
Submitted:  Mon 09 Sep 2013 07:48:38 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  andy1978
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 19 Aug 2014 03:56:03 PM UTC, comment #22: 

It all looks good to me.  It may not be clear to
all users that both the buttons and the edit menu
can be used, but this is a minor documentation issue.

Michael Godfrey <godfrey>
Group Member
Fri 01 Aug 2014 05:54:59 AM UTC, comment #21: 

Michael should have the last word, but with cset 19cb2530c16b the issue seems to be resoved for me.

Rik <rik5>
Group administrator
Thu 31 Jul 2014 09:55:00 PM UTC, comment #20: 

@Michael: I've also noticed this "jumping" and made some bigger changes for the fltk toolkit the last weeks. This should be fixed now on default. Could you please try this and report if its solved? Thanks, Andy

Andreas Weber <andy1978>
Group Member
Wed 11 Sep 2013 11:57:30 PM UTC, comment #19: 

Rik,

It appears that your bug fix (hack) of bug #400005
has affected the "jumping" problen in this
report.  The "jumping" still happens, but now
after there is no cursor motion, both windows go
back to having axes as they should be.

I also noticed (this may have been true before) that
the amount of the vertical "jump" is proportional
to the difference in vertical size of the two windows.
If you resize one of the windows so that they are the
same height again, then the axes flicker but do not jump.
So, in some way code is being executed that appears to use
the axes values for the wrong window.

Also, note that only the vertical axis is affected.  I
could not cause any "jumping" in the horizontal
direction by, for instance modifying the width of one
of the windows.


Michael Godfrey <godfrey>
Group Member
Wed 11 Sep 2013 03:52:33 AM UTC, comment #18: 

Just to clarify:  No mouse click is required
for the "jumping" behavior.  Only the cursor
passing over the figure window is sufficient.

This may help in locating the problem.

Michael Godfrey <godfrey>
Group Member
Wed 11 Sep 2013 02:25:00 AM UTC, comment #17: 

One thing I find that really shows the problem is to click on the window bar of figure1 and figure2.  Apparently, the click is causing a re-draw but with the click outside the canvas area of the plot the result is messed up.

Rik <rik5>
Group administrator
Wed 11 Sep 2013 02:20:15 AM UTC, comment #16: 

I'll re-open the bug report.  The original problem is fixed.  The "jumping" behavior you describe is something different.  It sounds related to the changes that were implemented to get the mouse correctly working with the right axis in subplot.

Rik <rik5>
Group administrator
Wed 11 Sep 2013 12:12:09 AM UTC, comment #15: 

Rik,

This (3cf4250cc67e) did some good.

figure(1)
figure(2)
now produces windows of the same size.

And, initially, there is no "jumping" of plots
in the windows.

However, the following sequence still breaks:

figure(1)
figure(2)

click on "G" in each window.
The 2 windows are the same size and each has a grid
0-1 on each axis.  Now drag the lower edge of figure(2)
so that it is vertically bigger than figure(1).

Now, when you move the cursor between 1 and 2 the
plots "jump."  For example, clicking on Fig 1 may
cause the plot in fig 2 to jump down.  Clicking on
fig 2 causes it to recover its size and position.

Better, but not fixed.

Note that this is a new problem.  It is not resolved
by doing
figure(1)
close(1)

at the beginning.

Michael Godfrey <godfrey>
Group Member
Tue 10 Sep 2013 04:51:21 PM UTC, comment #14: 

I get the correct result before and after Rik's change.

Ben Abbott <bpabbott>
Group Member
Tue 10 Sep 2013 04:24:25 PM UTC, comment #13: 

Fix pushed in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/3cf4250cc67e).  Closing report.

Rik <rik5>
Group administrator
Tue 10 Sep 2013 03:56:13 PM UTC, comment #12: 

works for me now.

Muhali <muhali>
Tue 10 Sep 2013 03:43:31 PM UTC, comment #11: 

I can now reproduce this with 1.3.0-5 thanks to Michael's explicit instructions.  Starting on the command line,


run-octave -f -q --no-gui
graphics_toolkit fltk
figure(1)
figure(2)
get(1:2, "position")
ans =
{
  [1,1] =

     304   175   560   440

  [2,1] =

     304   175   560   420

}


The problem seems to be related to scripts/private/__add_default_menu__ which is called by figure.  This script itself is trying to hack around the fact that the menubar property is not respected correctly in the C++ code.

If someone can try the attached menubar.cset and verify it I will commit it.


(file #29093)

Rik <rik5>
Group administrator
Tue 10 Sep 2013 03:22:09 AM UTC, comment #10: 

I just tried fltk-1.3.0-8.fc18.x86_64.rpm and
fltk-devel-1.3.0-8.fc18.x86_64.rpm

This level seems to behave like 1.3.0.10:
From a new invocation of octave I get second
figure less high and "jumping" of axes.

If I do close all
then
figure(1)
figure(2)
and plot data, the figures are the same size and no
"jumping."

Thus, 1,3.0-8 and 1.3.0.-10 appear to behave
the same.

Also,
octave
figure(1)
figure(2)
close(1)
figure(1)

works correctly.


Is everyone aware that these results depend on
a new invocation of octave?  Clear all does not
produce the same effect as:
quit
octave

or, in any case, close(1).

Michael Godfrey <godfrey>
Group Member
Tue 10 Sep 2013 03:05:31 AM UTC, comment #9: 

I see the same change in the height property with FLTK 1.3.2 on Debian.


octave:1> figure (1);
octave:2> figure (2);
octave:3> get (1:2, "position")
ans =
{
  [1,1] =

     300   200   560   440

  [2,1] =

     300   200   560   420

}


Mike Miller <mtmiller>
Group Member
Tue 10 Sep 2013 02:33:02 AM UTC, comment #8: 

This is weird.  fltk 1.3.0-10 is the base release
for Fedora 19, so I cannot downgrade.  And, there
is no upgrade.  I can try downloading the source and
compile it or look for an rpm that will install.



Michael Godfrey <godfrey>
Group Member
Tue 10 Sep 2013 01:34:32 AM UTC, comment #7: 

I'm using fltk-devel @1.3.x-r9949_0. The sources are from the link below.

http://fltk.org/pub/fltk/snapshots/

1.3.x-r9949_0 is a snapshot of version 1.3.2 from June 28th.

It is odd that 1.3.0-5 works, 1.3.0-10 does not, but 1.3.2 does.

Ben Abbott <bpabbott>
Group Member
Tue 10 Sep 2013 12:49:27 AM UTC, comment #6: 

The test code works for me on a Linux system, FLTK is version 1.3.0-5 which is ever so slightly different from the 1.3.0-10 that Michael reported for Fedora.  I also don't get the jumping that was reported.

Rik <rik5>
Group administrator
Mon 09 Sep 2013 03:52:12 PM UTC, comment #5: 

Ben,

There do seem to be some initialization problems left.
(Much better than it was, of course.)

Here are things I have observed by simple experiments
with the current dev system:

1. When a figure is first opened by figure(1)
   The coordinate values in the bottom toolbar are
   apparently random uninitialized values in floating
   point format. Usually the exponent is e-316. These
   values appear when the cursor is moved over the figure
   window. The values vary randomly as you move the
   cursor over the window.  This is a recent change. 
   Previously (3.6.4) the position values only changed
   after some data were plotted.
   But, it would be good if the variables
   that should be the x,y coordinates were initialized.
   After a plot is drawn they do take on the expected values.
   Clicking on the "G" button draws a grid with both axes
   [0,1] and the cursor position values are correct.

2. If 2 figures are drawn, and data are plotted then, usually,
   each window "jumps" when the cursor is passed over it.
   The "jump" takes the form of the axes jumping up or
   down by about the toolbar height and then returning to
   the original position. Similar "jumps" may be produced
   by setting focus on one figure and then mouse clicking
   on the title bar of another window. While the mouse
   button is held down the axes move in both the old and
   new figures (typically down in the new figure and up in
   the old figure).  When the mouse button is released they
   both more back.  Also, this jumping takes place whenever
   the cursor passes over a window (without any mouse
   clicks.

3. When modifying plots and using the cursor the following
   "stuff" appears in the window from which the plots
   were created:
octave:1> figure(1)
octave:2> figure(2)
octave:3> error: axis: expecting no args, or a vector with 2, 4, or 6 elements
error: called from:
error:   /usr/local/share/octave/3.7.6+/m/plot/axis.m at line 306, column 5
error:   /usr/local/share/octave/3.7.6+/m/plot/axis.m at line 149, column 7
error: octave_base_value::double_value (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: A(I,J): row index out of bounds; value 1 out of bound 0
figure(1)
error: axis: expecting no args, or a vector with 2, 4, or 6 elements
error: called from:
error:   /usr/local/share/octave/3.7.6+/m/plot/axis.m at line 306, column 5
error:   /usr/local/share/octave/3.7.6+/m/plot/axis.m at line 149, column 7
error: invalid graphics handle
error: invalid graphics handle
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: drawnow: A(I,J): row index out of bounds; value 1 out of bound 0
octave:3> error: axis: expecting no args, or a vector with 2, 4, or 6 elements
error: called from:
error:   /usr/local/share/octave/3.7.6+/m/plot/axis.m at line 306, column 5
error:   /usr/local/share/octave/3.7.6+/m/plot/axis.m at line 149, column 7
error: octave_base_value::double_value (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: A(I,J): row index out of bounds; value 1 out of bound 0
figure(2)
octave:3> quit

These messages do not occur in 3.6.4.

All this points to some inconsistency in the figure data:
some parts of the code hold one set of position data and
another has a different set.

This behavior is not present in 3.6.4.  So, this is a
regression.  When several plots are open this "jumping"
is fairly distracting.  Also, in 3.6.4 when 2 figures are
opened they both have the same height. (380, not 420 or 440)
Also, note that in 3.6.4 the selection of a figure by
mouse clicking on it did not work.  So, the implementation
of this feature may have had some unintended side-effects.

It may be that "bisect" can isolate the changeset that
introduced this.


Michael Godfrey <godfrey>
Group Member
Mon 09 Sep 2013 01:43:24 PM UTC, comment #4: 

I do not have this problem after a clean start.  However, I have observed that FLTK behaves differently on Linux and MacOSX.

I'm happy to test any proposed patches on MacOSX, and/or answer questions about my recent changes to _init_fltk_.cc


Ben Abbott <bpabbott>
Group Member
Mon 09 Sep 2013 12:54:48 PM UTC, comment #3: 

Current tip on fc 19:
octave:1> figure(1)
octave:2> figure(2)
octave:3> get(1:2, "position")
ans =
{
  [1,1] =

     1116    341    560    440

  [2,1] =

     1194    361    560    420

}
fltk-1.3.0-10.fc19.x86_64

Michael Godfrey <godfrey>
Group Member
Mon 09 Sep 2013 12:30:11 PM UTC, comment #2: 

I am using fltk 1.3.0.

The described behavior occurs only after a clean start, closing the figures is not enough.

Muhali <muhali>
Mon 09 Sep 2013 12:19:35 PM UTC, comment #1: 

I'm running MacOSX 10.7.5, with FLTK 1.3.2


figure(1)
figure(2)
get(1:2, "position")
ans =
{
  [1,1] =

     300   200   560   420

  [2,1] =

     300   200   560   420

}


Muhali, what version of FLTK is your octave using?

Ben Abbott <bpabbott>
Group Member
Mon 09 Sep 2013 07:48:38 AM UTC, original submission:  

When plotting two figures, figure 2 is slightly smaller than figure 1, roughly by the width of the toolbar.


graphics_toolkit fltk
figure(1)
figure(2)
get(1:2, "position")


ans =
{
  [1,1] =

     300   200   560   440

  [2,1] =

     300   200   560   420

}

I am using the current tip.

Muhali <muhali>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29093:  menubar.cset added by rik5 (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by muhali (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-08-19 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2014-08-01 rik5 StatusConfirmed Ready For Test
    2014-07-31 andy1978 Assigned toNone andy1978
    2013-09-11 rik5 StatusFixed Confirmed
        Open/ClosedClosed Open
    2013-09-10 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2013-09-10 rik5 Attached File- Added menubar.cset, #29093
        StatusWorks For Me Patch Submitted
    2013-09-09 bpabbott StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code