[Octave-bug-tracker] [bug #59731] wrong colorbar length when aspect ratio is manual

[Hg200]

Follow-up Comment #8, bug #59731 (project octave):

I did further research on __actual_axis_position__ (). As guessed in comment
#7, this function calculates the position and size of the "image of the axes
after applying the aspect ratio". To understand why this is needed, one must
understand how objects are plotted in the Octave opengl-renderer. In
graphics.cc

++
void axes::properties::update_camera (void)
--

the view and projection matrices are composed as a function of the viewpoint,
target, up vector and the bounding box. The aspect ratio of the data is taken
into account in the view matrix "x_gl_mat1". In a second step, the FOV is
fitted into the bounding box. In simplified terms, this is basically
controlled by the projection "x_gl_mat2". 

A color bar must now be scaled based on the actual visible "image of the axes"
in the figure after all those transformations. Therefore it is necessary to
know the position of the axes after the projection (aspect ratio, rotation).
IMO, the correct way to do this would be to create an internal variable in
graphics.cc that specifies the final image size after projection. Now, the
code in __actual_axis_position__ () also tries to calculate what the aspect
ratio does to the image. For 2D this is easy, but for 3D it is a nightmare.

The code is not only messy, but also vulnerable. For example, it generates
wrong color bar lengths when the unit is set to pixels before calling
colorbar. The following test code produces color bars with two different
lengths: 

++
hax = axes ();
sombrero;
view(2)
daspect ([1,1,1]);
set (hax, 'units', 'normalized');
colorbar('south');
figure;
hax = axes ();
sombrero;
view(2)
daspect ([1,1,1]);
set (hax, 'units', 'pixels');
colorbar('south');
--

This is due to line 54, where axis_obj.outerposition depends on the current
unit setting of the axes. If the unit is "pixels", this conversion is wrong:

++
pos_in_pixels = axis_obj.outerposition .* fig_position([3, 4, 3, 4]);
--

I think, based on what we know now, I can try to create a fix for colorbar.m
under the prerequisites that are mentioned in comment #7. -> colorbar length
calculation is omitted in 3D / manual mode, but is taken into account for 2D
plots.  

    _______________________________________________________

Reply to this item at:

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

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