bugGNU Octave - Bugs: bug #52732, plot shrinks horizontally on...

 
 

bug #52732: plot shrinks horizontally on replotting

Submitter:  A.R. Burgers <arb>
Submitted:  Sat 23 Dec 2017 10:14:18 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 28 Dec 2017 06:07:40 AM UTC, comment #3: 

I fixed this for colorbar, and also for legend, in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/b4e371b5f6b5).

The code failed to make a distinction between axes being deleted, in which case there was no need to restore their original position, versus axes being reset (such as by a new plot) in which case the axes did need to be restored.

Rik <rik5>
Group administrator
Sun 24 Dec 2017 04:10:59 AM UTC, comment #2: 

Note that all of the following 'off', 'hide', 'delete' appear to work correctly.  (Although, I am wondering what th difference is between 'off' and 'hide'... I would think that maybe 'off' should disable the colorbar such that the main plot goes back to the larger size while 'hide' doesn't show the colorbox but still occupies space so that the main plot remains smaller.)


close all;
graphics_toolkit('qt');
image;
myhcb = colorbar()
colorbar('off');
colorbar('hide');
colorbar('delete');


The issue arises when doing another plot.  Try the following:


close all;
graphics_toolkit('qt');
image;
myhcb = colorbar()
image;
get(myhcb)


The follow-up image command removes the colorbar so that it is no longer valid.  That might be OK, if only the position were restored first just like what happens with colorbar('delete').  Maybe it is as simple as somehow issuing the delete to the color bar.

I'm curious what happens on 4.2.1.  With the second "image;" command is the colorbar visible?  Or does it disappear with a new plot?  My guess would be the colorbar goes away; that seems to be the model, i.e., create the plot first and then decorate it--not the other way around.

Dan Sebald <sebald>
Sun 24 Dec 2017 03:06:19 AM UTC, comment #1: 

Confirmed here on linux.

I see what the issue is, but before going forward I'll let Rik look at this a bit because (although this isn't a consequence of legend) he's been looking at the legend code and inside this colorbox.m code is this comment with regard to subfunction _position_colorbox_:


## FIXME: The algorithm for positioning in legend.m is much more sophisticated
##        and should be borrowed for colorbar.  One problem is that colorbar
##        positioning does not take in to account multi-line axes labels
function [pos, cpos, vertical, mirr] = __position_colorbox__ (cbox, props, cf)


So, maybe he has the legend layout fresh in his mind and sees a way to address this and can remove the above FIXME comment.

The issues is basically the following code:


hax
    [pos, cpos, vertical, mirror] = __position_colorbox__ (loc, props, hpar);
pos
cpos
    set (hax, "position", pos);


in which the colorbar position is computed and a new position for the plot is computed.  If this is called repeatedly with every replot (and the parent axes are not deleted) the position properties of the parent axes keep getting updated.  That's what is happening, which the printout below shows.  Note that one would think that the above hunk of code would only be called once and conditioned out of the flow if the colorbox already exists.  However, I've printed out some items (see above) that illustrate the colorbox keeps being deleted with every replot while obviously the parent axes are not being deleted.  And I think that is what the core problem is.


octave:9> close all
ans = INSIDE __cb_axes_deleted__
octave:10> for i = 1 : 5
>     % close all
> %    trisurf(tri, x, y, x + y);
> image();
>     view(2);
>     myhcb = colorbar()
>     pause
> end
hax = -13.659
ans = INSIDE __position_colorbox__
pos =

   0.13000   0.11000   0.62000   0.81500

cpos =

   0.827500   0.110000   0.046500   0.815000

myhcb = -7.2883
ans = INSIDE __cb_axes_deleted__
hax = -13.659
ans = INSIDE __position_colorbox__
pos =

   0.13000   0.11000   0.49600   0.81500

cpos =

   0.688000   0.110000   0.037200   0.815000

myhcb = -7.5177
ans = INSIDE __cb_axes_deleted__
hax = -13.659
ans = INSIDE __position_colorbox__
pos =

   0.13000   0.11000   0.39680   0.81500

cpos =

   0.576400   0.110000   0.029760   0.815000

myhcb = -7.8976


Dan Sebald <sebald>
Sat 23 Dec 2017 10:14:18 PM UTC, original submission:  

See the next script:


x = rand(10, 1); y = rand(10, 1);
tri = delaunay(x,y);
graphics_toolkit('qt');
graphics_toolkit('gnuplot');
for i = 1 : 5
    % close all
    trisurf(tri, x, y, x + y);
    view(2)
    colorbar();
    pause
end


On every iteration of the loop the plot shrinks horizontally

  • both for qt and gnuplot toolkits
  • no shrinking for octave-4.2.1
  • no shrinking if all plots are closed before trisurf call
  • no shrinking if there is no colorbar


A.R. Burgers <arb>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by arb (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-12-28 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code