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!
|
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.
|
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.
|
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.
_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?
|
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
|
Fri 19 Jul 2013 10:12:57 PM UTC, comment #2:
Your code returns:
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.
|
Fri 19 Jul 2013 09:40:57 PM UTC, comment #1:
Can someone with access to Matlab run the following code?
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.
|
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:
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.
|