[Octave-bug-tracker] [bug #47974] Visual differences between gnuplot and OpenGL toolkits

[Dan Sebald]

Follow-up Comment #23, bug #47974 (project octave):

I was wrong about the previous changeset for axes visibility.  It doesn't
break the Qt behavior.

Well, to move this along I'm attaching a debugging type of patch where I've
changed a few lines of code and display some info to try to make sense of what
is being called and when (debug_axes_pos_djs2016may25.diff).  Rather than
leave margins up to gnuplot, I've set them to the axes position... that may
not be the correct thing to do, but it is illustrating the behavior.  This
outputs for me:

pos =

   0   0   1   1

ans = axes
ans =

   0.13000   0.11000   0.77500   0.79714

ans = HI 1
ans = HI 11
pos =

   0   0   1   1

ans = axes
ans =

   0   0   1   1

ans = HI 1
ans = HI 2
ans = HI 3
ans = HI 4

OK, so the first half of this output is the plot of the data (linear curve)
and that is the one having a setting of "outerposition" (prints out HI 11). 
Ben could you explain a couple things about what we're seeing?

1) What is pos (i.e., __actual_axis_position__()) supposed to represent?  It
has it's actual position at [0 0 1 1].  How could that be an axes position?

2) The axes position property is


>> get(kids(4),'position')
ans =

   0.13000   0.11000   0.77500   0.79714


but I don't see what that could possibly represent on any of the reference
frames.  Any idea what that is?

Just looking at the scant evidence, I would guess that
__actual_axes_position__() isn't telling us the correct answer for the data
drawing pass through the loop.

(file #37267)
    _______________________________________________________

Additional Item Attachment:

File name: debug_axes_pos_djs2016may25.diff Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47974>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/