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

 
 

bug #39988: standard height of figures changes

Submitted by:  Muhali <muhali>
Submitted on:  Mon 09 Sep 2013 07:48:38 AM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: Andreas Weber <andy1978>
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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,

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

Mike Miller <mtmiller>
Project Administrator
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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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

Muhali, what version of FLTK is your octave using?

Ben Abbott <bpabbott>
Project 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.

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 File(s):
   
   
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
  • -unavailable- added by andy1978 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by muhali (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 19 Aug 2014 04:46:18 PM UTCrik5StatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Fri 01 Aug 2014 05:54:59 AM UTCrik5StatusConfirmed=>Ready For Test
    Thu 31 Jul 2014 09:55:00 PM UTCandy1978Assigned toNone=>andy1978
    Wed 11 Sep 2013 02:20:15 AM UTCrik5StatusFixed=>Confirmed
      Open/ClosedClosed=>Open
    Tue 10 Sep 2013 04:24:25 PM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Tue 10 Sep 2013 03:43:31 PM UTCrik5Attached File-=>Added menubar.cset, #29093
      StatusWorks For Me=>Patch Submitted
    Mon 09 Sep 2013 12:19:35 PM UTCbpabbottStatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1