bugGNU Octave - Bugs: bug #39529, graphics functions: unneeded new...

 
 

bug #39529: graphics functions: unneeded new axis when parent is specified as prop/val

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Fri 19 Jul 2013 05:24:45 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
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
   

Jump to the original submission

Thu 25 Jul 2013 03:54:49 PM UTC, comment #7: 

Rik,

I ran some plotting tests based on the current
devel.  Found no regressions.

In any case, I am sure that this will make progress
easier.

Bug #39546 is the same as it was.  The main thing that
needs a fix is that the "G" menu button appears
to unconditionally use the axis handle of the last drawn
subplot.  Pan and zoom use the axis handle of the subplot
where the cursor is, so that works just fine. It is not
obvious how to select the right axis handle for the
"G" button.  Maybe left clicking on the subplot should
do it?

When I was looking at this I had some trouble until I
discovered that subplot() returns the axis handle.
I will do a documentation patch for that.

Thanks for a lot of helpful work!

Michael Godfrey <godfrey>
Group Member
Thu 25 Jul 2013 06:18:53 AM UTC, comment #6: 

Fixed in a massive set of changesets upgrading everything to use an updated version of newplot().  Thanks for the help on this one.  Closing report.

Rik <rik5>
Group administrator
Sun 21 Jul 2013 01:23:27 PM UTC, comment #5: 

Your approch seems reasonable. However, as many graphics functions rely on plt_get_axis_args, I would not change its behavior. I think it should always return an axes handle.

Why not call newplot in plt_get_axis_args :
 - if a parent axes is specified in any form, call "hax = newplot (hax)"
 - if none is specified, call "hax = newplot ()" instead of "gca ()".


The workflow would then be:
 - implement "newplot (handle)" which doesn't work yet
 - modify _plt_get_axis_args
 - remove superfluous calls to "newplot ()" from the graphics functions that already use it.


 




Pantxo Diribarne <pantxo>
Group Member
Sun 21 Jul 2013 02:47:14 AM UTC, comment #4: 

I think the overall structure of creating a new plot is broken.  First, unneeded new axes occasionally get created.  Second, the axes() function is not behaving in a compatible way.  And once we do make it compatible, it will make the Octave behavior look even worse.

I've been looking into the situation and I think that Matlab relies on newplot() to do most of the work.  So, I'm thinking that Octave should re-code to the following syntax for plotting routines.


[hax, varargin, nargs] = __plt_get_axis_args (...);
oldfig = ifelse (isempty (hax), [], get (0, "currentfigure"));
unwind_protect
  hax = newplot (hax);
  ... CODE ...
unwind_protect_cleanup
  if (! isempty (oldfig) && isfigure (oldfig))
    set (0, "currentfigure", oldfig)
  endif
end_unwind_protect


_plt_get_axis_args_ would be modified to just examine varargin and return hax or a null value, but not to create any figures or axes.  Instead of switching axes with the axes() command I would switch figures.  Since the current axis is maintained as a property of the figure object this avoids having to call axes() and all the problems associated with that.  Once the figure is restored the current axis will automatically be correct again.

What do you think?

Rik <rik5>
Group administrator
Fri 19 Jul 2013 10:48:15 PM UTC, comment #3: 

I forgot to mension that setting the currentaxes using "axes (ca)" is not a good idea. "axes (handle)" should not only change the currentaxes (the only thing it currently does) but also the order of the children in the stack [1]: the handle is promoted to the top level wich is not what we want here.

[1] http://www.mathworks.fr/fr/help/matlab/ref/axes.html

Pantxo Diribarne <pantxo>
Group Member
Fri 19 Jul 2013 10:12:57 PM UTC, comment #2: 

Your code returns:

hf1 =
     1

hax1 =
  173.0011

hf2 =
     2

hax2 =
  347.0011

ans =
  347.0011

ans =
  347.0011

ans =
     2

ans =
  347.0011

ans =
     2

So octave just works as expected here. My interrogation is does octave really have to change the currentaxes before processing the graphics objects in lower level functions? Why not let it as is? AFAICS currentaxes is just the (default) axes which is used if none has been specified.

Pantxo Diribarne <pantxo>
Group Member
Fri 19 Jul 2013 09:40:57 PM UTC, comment #1: 

Can someone with access to Matlab run the following code?


hf1 = figure (1)
hax1 = axes
hf2 = figure (2)
hax2 = axes
gca
plot (hax1, 1:5)
gca
gcf
plot (5:-1:1, 'parent', hax1)
gca
gcf


I'm trying to see if Matlab saves and restores the current figure and axis.

Right now Octave uses unwind_protect blocks to do saving/restoring but it might be simpler to switch gca to the named axis (like hax1 in the example) and just leave it there.

Rik <rik5>
Group administrator
Fri 19 Jul 2013 05:24:45 PM UTC, original submission:  

Following bug http://savannah.gnu.org/bugs/?39483

When there is no current axes, e.g. when the current figure is empty, many graphics functions create a new axes even when the target parent axes was specified through prop/val pair.

The following code demonstrates the problem:

figure (1);
ax = axes ();
figure (2)
text (.5, .5, "toto", "parent", ax)
get (2, "currentaxes")


Populating "ax" in figure 1 should not create any axes in figure 2. The problem lies in the generalized use of "gca ()" which creates a new axes when none is found in the current figure.

Attached is a patch that solves that problem for text.m, plot.m, surface.m and image.m (patch.m doesn't suffer this problem). I can list the high level functions such as plot.m that suffer this issue if needed.

 








Pantxo Diribarne <pantxo>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #28618:  graphics_avoid_gca.diff added by pantxo (3KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-25 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2013-07-19 pantxo Attached File- Added graphics_avoid_gca.diff, #28618

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code