bugGNU Octave - Bugs: bug #48273, Incorrect axes position updates in...

 
 

bug #48273: Incorrect axes position updates in OpenGL plotting

Submitter:  Muhali <muhali>
Submitted:  Mon 20 Jun 2016 09:11:46 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Muhali 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

Thu 13 Dec 2018 08:17:03 PM UTC, comment #22: 

Marking this bug as fixed and closing report.

There was an additional item mentioned about limiting the number of ticks and labels when they begin to overlap because of crowding axes.  If interested, someone should file a new report about that.

Rik <rik5>
Group administrator
Fri 26 Oct 2018 03:09:53 PM UTC, comment #21: 

I thought a bit about setting a limit on the number
of stacked subplots (in x and y). But, for most users
just looking at the plot should be enough for them
to realize whether they have tried to fit too many
subplots within a single plot area.
And, it is possible
that someone could want the end result to be a huge poster...

An intrasubplot spacing parameter may be needed?

I currently do not have access to Matlab. But, useful
to know what it does.

Michael Godfrey <godfrey>
Group Member
Fri 26 Oct 2018 02:51:15 PM UTC, comment #20: 

Yeah, I'm not sure what to do about the lack of space.  If someone is interested in working on this, then we could try to reduce the spacing between subplots.  Possibly that belongs in the subplot function itself.  We could also limit the number of tick mark labels when they begin to overlap.  We should probably be doing this anyway to handle combinations of plot, font, and label size.  I assume this job, will have to be done in the rendering code, possibly with feedback to the graphics properties to reflect the loss of tick labels.  What do users expect?  What does Matlab do?  In any case, it is not critical to me, but would be nice to produce pleasing results automatically.  Unfortunately, I think that tends to be difficult to do well.

John W. Eaton <jwe>
Group administrator
Fri 26 Oct 2018 02:41:11 PM UTC, comment #19: 

jwe: This is a lot better. Even n=44 for my case below
looks OK, except that the plots are so compressed that it
is hard to see them. Other n values all seem OK.

And, a few other subplot examples work as before.



Michael Godfrey <godfrey>
Group Member
Thu 25 Oct 2018 08:22:34 PM UTC, comment #18: 

Oops, something went wrong with the verbatim tags in my previous comment.  Here it is again:


After looking at this for a bit longer, I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/d85049849e88

This improves things significantly for me, but we can probably still do better.

Given the following function, I can get plots on the screen for a large range of values for NR and NC.


function foofcn (nr = 2, nc = 2)
  set(0, 'defaultfigureunits', 'normalized') ;
  set(0, 'defaultfigureposition', [0.7   0.7   0.25   0.25]) ;

  clf ;
  n = nr * nc;
  x = randn(3,n) ;
  for j=1:n
    subplot(nr,nc,j) ;
    plot(x(:,j)) ;
  endfor
  print foo.png
end


However, I see the following ghostscript error on printing to a png file when using NR=1 and NC=25 (for example).


Error: /undefined in -nan
Operand stack:
   --nostringval--   (-2.5)   --nostringval--   0
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   2043   1   3   %oparray_pop   2042   1   3   %oparray_pop   --nostringval--   2023   1   3   %oparray_pop   1884   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:969/1684(ro)(G)--   --dict:0/20(G)--   --dict:83/200(L)--   --dict:42/64(L)--
Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.25: Unrecoverable error, exit code 1


So it looks like we may still be generating some bad values.  I would also guess that we will also fail for large enough numbers of subplots no matter what the orientation.  But rather than place an arbitrary limit in the subplot function, I think it would be better to try to fix the plotting code to detect bad values if/when they are generated.  That way, any plotting code that attempts to do something silly will fail with an error message instead of just avoiding the problem in the subplot function.


John W. Eaton <jwe>
Group administrator
Thu 25 Oct 2018 08:17:44 PM UTC, comment #17: 

After looking at this for a bit longer, I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/d85049849e88

This improves things significantly for me, but we can probably still do better.

Given the following function, I can get plots on the screen for a large range of values for NR and NC.


function foofcn (nr = 2, nc = 2)
  set(0, 'defaultfigureunits', 'normalized') ;
  set(0, 'defaultfigureposition', [0.7   0.7   0.25   0.25]) ;

  clf ;
  n = nr * nc;
  x = randn(3,n) ;
  for j=1:n
    subplot(nr,nc,j) ;
    plot(x(:,j)) ;
  endfor
  print foo.png
end
+verbatim-

However, I see the following ghostscript error on printing to a png file when using NR=1 and NC=25 (for example).

+verbatim+
Error: /undefined in -nan
Operand stack:
   --nostringval--   (-2.5)   --nostringval--   0
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   2043   1   3   %oparray_pop   2042   1   3   %oparray_pop   --nostringval--   2023   1   3   %oparray_pop   1884   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:969/1684(ro)(G)--   --dict:0/20(G)--   --dict:83/200(L)--   --dict:42/64(L)--
Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.25: Unrecoverable error, exit code 1


So it looks like we may still be generating some bad values.  I would also guess that we will fail for large enough numbers of subplots.  But rather than place an arbitrary limit in the subplot function, I think it would be better to try to fix the plotting code to detect bad values if/when they are generated.  That way, any plotting code that attempts to do something silly will fail with an error message instead of just avoiding the problem in the subplot function.

John W. Eaton <jwe>
Group administrator
Thu 25 Oct 2018 02:54:45 PM UTC, comment #16: 

The problem appears to be that the position properties are screwed up when the axes and labels won't fit inside the outerposition bounding box.  For example, try this modified script and see what happens to the position, outerposition, and tightinset properties:


set(0, "defaultfigureunits", "normalized") ;
set(0, "defaultfigureposition", [0.7   0.7   0.25   0.25]) ;

clf ;
n =  15;
x = randn(3,n) ;
for j=1:n
   subplot(n,1,j) ;
   plot(x(:,j)) ;
endfor
#print foo.png

ax = get (gcf, "children");

get (ax(5), "outerposition")
get (ax(5), "tightinset")
get (ax(5), "position")


With this script, I see


ans =

     0.00000   206.33737     1.00000  -412.07684

ans =

    0.0375000   13.7706152    0.0078125   13.7539474

ans =

     0.13000   220.10799     0.77500  -439.60140


The width of a bounding box should not be negative!

If I uncomment the print command I see an error from the gl2ps renderer and the results appear to be even worse:


warning: gl2ps_renderer::draw_axes: empty feedback buffer and/or nothing else to print
warning: called from
    __opengl_print__ at line 158 column 7
    print at line 574 column 14
    fooscript at line 12 column 1
ans =

   0.0000e+00   2.5315e+20   1.0000e+00  -5.0631e+20

ans =

   4.2188e-02   2.4746e+17   7.8125e-03   2.4746e+17

ans =

   1.3000e-01   2.5340e+20   7.7500e-01  -5.0680e+20


I'm not sure whether the problem is with the computation of tightinset, looseinset, or the updates of the position properties and I can't really follow the logic of the update_position and update_outerposition functions.

Maybe this additional info will be enough to allow someone else who has a better understanding of the plotting properties to fix this problem.

Also, what is the looseinset property about?  Is it really necessary?

John W. Eaton <jwe>
Group administrator
Wed 24 Oct 2018 05:59:45 PM UTC, comment #15: 

Now I have gotten to n=22 with  no errors...
So, I do think that the problem starts when the plots
will no longer fit in the current window.

Michael Godfrey <godfrey>
Group Member
Wed 24 Oct 2018 05:55:34 PM UTC, comment #14: 

I just tried a simple experiment:
first: clf
Then increase the vertical size the the figure to about
twice what it was (most of available vertical space)

After that change n=12 works correctly. And, the plots
just about fill the available space. So, it appears
that what goes wrong starts when the plots fill the
size of the plot window.

Michael Godfrey <godfrey>
Group Member
Wed 24 Oct 2018 05:48:13 PM UTC, comment #13: 

WRT #10. Corollary, if i set fonts to 96 I get garbage at n=4.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 24 Oct 2018 05:47:22 PM UTC, comment #12: 

John,

I just tried fltk and it behaves very much like qt.
So, this suggests that the problem is in code that is
common to qt and fltk.

Michael

Michael Godfrey <godfrey>
Group Member
Wed 24 Oct 2018 05:39:44 PM UTC, comment #11: 

John,
I assume that you are commenting on my #8. I was just
running octave  --silent and using qt.

It seems very likely that bad values are being sent
to OpenGL. It appears that somehow the repeated calls
are overwriting data that has yet to be used by OpenGL
for the previous plot.

It also appears that this is a long outstanding problem.
I have not tested, but I am quite sure that it affects fltk
in similar ways.

Michael Godfrey <godfrey>
Group Member
Wed 24 Oct 2018 05:31:53 PM UTC, comment #10: 

I noticed if I reduce the default font size I can squeeze in more
subplots plofe I see the problem. Like I can do 15 (or may be more) with font size set to 4 (see attached).

Dmitri.



Dmitri A. Sergatskov <dasergatskov>
Wed 24 Oct 2018 01:47:20 PM UTC, comment #9: 

If you are using the --no-gui-libs option, then what graphics toolkit are you using?  fltk?

With either qt or fltk, I see the bug if N larger than 10 or so.  The display on the screen is also incorrect.

With gnuplot, it works, slowly, and each subplot taking longer to appear than the last.  The final plot is shown on the screen after Octave exits.

If I replace the two set(0,...) commands in the script with


set (0, "defaultfigureposition", [1000,100,560,1200])


then it works for larger values of N, but eventually fails again.

So now I'm thinking that when we try to place too many subplots in the figure, we end up sending bad values to the OpenGL library that result in garbage output.

John W. Eaton <jwe>
Group administrator
Wed 24 Oct 2018 12:13:00 PM UTC, comment #8: 

For me using current dev on FC28 I consistently
get n=8 works, n=9 fails. And, for n=9 resizing the
plot window causes the (nonsense) data, axes, and grid
lines to disappear.

It appears that something is corrupting much of
the plot data, axes, etc...

I tend to agree that this may not be a race condition,
but turning on the pause does affect the output.

And, producing the plot seems to "work" in that it
writes what is shown on the screen.

Michael Godfrey <godfrey>
Group Member
Mon 15 Oct 2018 04:31:46 PM UTC, comment #7: 

I can reproduce this bug with the --no-gui-libs option, so it has nothing to do with a race condition. Instead, it looks like it only has to do with drawnow being called after each subplot.

So there is no race condition involved here. Can I retitle to something like "Several subplots sometimes lead to corrupted axes position"?

Pantxo Diribarne <pantxo>
Group Member
Tue 28 Jun 2016 12:11:13 AM UTC, comment #6: 

Ok, I can confirm on the default branch with n=10 or higher.

Mike Miller <mtmiller>
Group Member
Tue 21 Jun 2016 11:01:57 PM UTC, comment #5: 

I could also reproduce it on the default branch under Linux Mint Debian Edition.

I'm not sure of the specs of my video system, but lshw gives


 *-display
    description: VGA compatible controller
    product: 2nd Generation Core Processor Family Integrated Graphics Controller
    vendor: Intel Corporation
    physical id: 2
    bus info: pci@0000:00:02.0
    version: 09
    width: 64 bits
    clock: 33MHz
    capabilities: vga_controller bus_master cap_list rom
    configuration: driver=i915 latency=0
-verbatim

Lachlan Andrew <lachlan>
Tue 21 Jun 2016 09:36:03 PM UTC, comment #4: 

This is a problem for me on the default branch. Increasing
n also makes it worse. Try n=20.
Also, it fails in the same way using qt and fltk.

It would be useful to determine on which systems this
is a problem and on which it always succeeds.

My system is Fedora 23 Intel NUC5i5RYH.

Of course, the final print command must be left out
since it always seg faults as is well-known.

Michael Godfrey <godfrey>
Group Member
Tue 21 Jun 2016 05:38:47 PM UTC, comment #3: 

This is not a problem for me on the default branch. Can you reproduce this on the default branch or only with 4.0.2?

If this only affects 4.0.2, I'm not sure it's worth pursuing for a possible stable bug fix, but don't let me stop you if you want to debug it.

Mike Miller <mtmiller>
Group Member
Tue 21 Jun 2016 07:20:31 AM UTC, comment #2: 

I'm renaming this from "subplot(9,1,.) gives garbage", and linking to two other problems with race conditions in the GUI.  Both of those result in segfaults, so I don't think this is a duplicate of either of them.

Lachlan Andrew <lachlan>
Mon 20 Jun 2016 10:44:34 AM UTC, comment #1: 

There has been a long-standing race condition in the
graphics code, but I am not sure if there is an open
bug report specifically on this. If not, this report
could be retitled, and the example can be used for debugging.

Michael Godfrey <godfrey>
Group Member
Mon 20 Jun 2016 09:11:46 AM UTC, original submission:  

By running


graphics_toolkit qt
set(0, "defaultfigureunits", "normalized") ;
set(0, "defaultfigureposition", [0.7   0.7   0.25   0.25]) ;

clf ;
n = 9 ;
x = randn(3,n) ;
for j=1:n
   subplot(n,1,j) ;
   plot(x(:,j)) ;
## pause(2) ;
endfor
print foo.png ;


as a script I get garbage with n>8 (see attached figure). By running interactively or by including the pause statement it works. Same for fltk.

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45284:  foo_das.png added by dasergatskov (22KiB - image/png)
file #37529:  foo.png added by muhali (8KiB - image/png)

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by godfrey (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 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-13 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-10-25 jwe StatusConfirmed Ready For Test
    2018-10-25 jwe SummaryRace condition in OpenGL plotting Incorrect axes position updates in OpenGL plotting
    2018-10-24 dasergatskov Attached File- Added foo_das.png, #45284
    2018-10-15 mtmiller Carbon-CopyRemoved 80942 -
    2016-06-21 lachlan Release4.0.2 dev
    2016-06-21 lachlan Dependencies- Depends on bugs #46501
    2016-06-21 lachlan Item GroupNone Incorrect Result
        StatusNone Confirmed
        Originator Name Muhali
        Summarysubplot(9,1,.) gives garbage Race condition in OpenGL plotting
        Dependencies- Depends on bugs #47650
    2016-06-20 muhali Attached File- Added foo.png, #37529

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code