On Thu, Jul 17, 2008 at 12:42 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Anyone have any thoughts on this? It seems like it's serious enough to try
> to resolve before the next bugfix release.
I think what we are seeing here is the known GUI figure canvas leak
(Michael, I think our offlist conversation about mainquit was a red
herring since removing that call doesn't help). We have found in the
past that creation of gtk canvases and tk canvases leak and this is
outside mpl. The reason that commenting out del Gcf.figs[num] "fixes"
the leak because it causes pyplot to simply reuse the figure rather
than re-call new_figure_manager. The chain of logic
_pylab_helpers.Gcf:
def get_fig_manager(num):
figManager = Gcf.figs.get(num, None)
if figManager is not None: Gcf.set_active(figManager)
return figManager
pyplot.figure
figManager = _pylab_helpers.Gcf.get_fig_manager(num)
if figManager is None:
if get_backend().lower() == 'ps': dpi = 72
figManager = new_figure_manager(num, figsize=figsize,
dpi=dpi,
facecolor=facecolor,
edgecolor=edgecolor,
frameon=frameon,
FigureClass=FigureClass,
**kwargs)
so when you do not del the figure number, the manager still lives in
the dictionary in Gcf and is returned by
_pylab_helpers.Gcf.get_fig_manager(num), and so subsequent calls to
new_figure_manager are not triggered (so the figure is not really
closed...)
So there is a bug here, but I am not sure it is in mpl -- I think it
is more likely to be in the GUI toolkits themselves, as we do not see
them in any of the mpl image backends. I don't think we need to hold
a release on this, since it is a known and existing problem with no
obvious mpl solution, though getting a reproducible test case that
just used the GUI code for submission to pygtk, tkinter, etc... would
be useful.
JDH
Michael and I just talked through this offlist, and it appears that
what is happening is that form any of the interactive backends, the
trigger to stop the GUI mainloop is when all the figures have been
closed. The typical use case in a script is to raise several GUI
figures and the program exits when all of them have been closed.
pylab otherwise doesn't know when to quit and return the shell prompt.
The backend first checks to see if you are in interactive mode, and
does not call main quit if you are, so this doesn't affect folks using
mpl in an ipython shell or other interactive sessions.
The only use case where it should arise is like the one in looptest,
where a script creates a GUI figure and then closes it in
non-interactive mode. Although there is a use case where this makes
sense (eg if we had a blocking show) where one would create a figure,
raise it, block, close it, rinse and repeat, this mode is not
currently supported in pylab (show would need to be smarter, though
with our new blocking input functions we might be able to attempt
this). This also does not affect applications since the close/destroy
handling is a pyplot construct.
Michael pointed out that the twinx problem was separate (and fixed) so
is unrelated to the close bug and can be removed from the looptest
test script.
There is a workaround for those who really need this functionality,
although it is unsupported currently, and that is simply to wrap the
close call in ion/ioff function calls to turn interaction on. The
interactive backends won't attempt to call mainquit if interactive
mode is on, so
PL.ion()
PL.close(1)
PL.ioff()
blocks this leak
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
