[Octave-bug-tracker] [bug #48273] Incorrect axes position updates in OpenGL plotting

[John W. Eaton]

Update of bug #48273 (project octave):

                  Status:               Confirmed => Ready For Test         

    _______________________________________________________

Follow-up 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).


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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?48273>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/