Exact semantics of ion()??

What does ion() exactly do? From reading the documentation, I gather that
the interactive mode is equivalent to issuing an automatic draw() after each
plotting comment. However, a program like the following one does not draw
anything (Matplotlib 1.0, both on Mac OS X and Windows):

from matplotlib import pyplot as pp

pp.plot([10, 20, 50])
pp.draw()

raw_input('Press enter...') # No graph displayed?!!
<<<

However, adding ion() and removing the draw() displays the graph. So, it
looks like the interactive mode does more than what I gather from the docs.
What does ion() do in addition to adding an automatic draw()? Can the above
program be modified so as to draw the graph but without using ion()?

Any input would be much appreciated!

EOL

PS: the documentation I was referring to reads: "The interactive property of
the pyplot interface controls whether a figure canvas is drawn on every
pyplot command. If interactive is False, then the figure state is updated on
every plot command, but will only be drawn on explicit calls to draw(). When
interactive is True, then every pyplot command triggers a draw."

···


View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31728909.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

What does ion() exactly do? From reading the documentation, I gather that
the interactive mode is equivalent to issuing an automatic draw() after each
plotting comment. However, a program like the following one does not draw
anything (Matplotlib 1.0, both on Mac OS X and Windows):

from matplotlib import pyplot as pp

pp.plot([10, 20, 50])
pp.draw()

raw_input('Press enter...') # No graph displayed?!!
<<<

However, adding ion() and removing the draw() displays the graph. So, it
looks like the interactive mode does more than what I gather from the docs.
What does ion() do in addition to adding an automatic draw()? Can the above
program be modified so as to draw the graph but without using ion()?

Any input would be much appreciated!

EOL

PS: the documentation I was referring to reads: "The interactive property of
the pyplot interface controls whether a figure canvas is drawn on every
pyplot command. If interactive is False, then the figure state is updated on
every plot command, but will only be drawn on explicit calls to draw(). When
interactive is True, then every pyplot command triggers a draw."

Turning interactive mode on also means an implied "show" command, if
needed. The first program can replace draw() with show(). However,
if interactive mode is off, then the python execution pauses. With it
on, python execution will continue.

Note, there are some issues with the macosx backend (and it still
exists) with respect to interactive mode. When on your Mac, you can
use one of the other backends for intended behavior. Also, there were
a number of additional bug fixes with the backends between 1.0.0 and
1.0.1.

I hope this clears things up,
Ben Root

···

On Sunday, May 29, 2011, Eric O LEBIGOT (EOL) <Eric.Lebigot@...1818...> wrote:

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31728909.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Thank you for your response.

Benjamin Root-2 wrote:

What does ion() exactly do?
$$$
from matplotlib import pyplot as pp

pp.plot([10, 20, 50])
pp.draw()

raw_input('Press enter...') # No graph displayed?!!
$$$

Turning interactive mode on also means an implied "show" command, if
needed. The first program can replace draw() with show(). However,
if interactive mode is off, then the python execution pauses. With it
on, python execution will continue.

So, if anything is drawn when interactive mode is off, does one *have* to
use show() at the end? in other words does using a single raw_input() at
the end of the program force the use of the interactive mode for *all*
figures? (Closing all the figures with a simple "enter" is very convenient,
but having a performance penalty for this would not be so nice…).

Now, if I understand you correctly, I have another question. I don't
understand anymore what draw() does: in fact, it is not necessary in
interactive mode, and it does not appear to do anything in non-interactive
mode, since show() is really the function that really displays the figures.
So, why does matplotlib offer draw()? what does it really do?

EOL

PS: Here is an example: the following code does *not* display the first
figure (Matplotlib 1.0.0 on Mac OS X with the GTKAgg backend):
$$$
from matplotlib import pyplot as pp

pp.figure()
pp.plot([10, 20, 50])
pp.draw() # Will not be displayed despite the draw()

pp.ion() # Interactive mode on
pp.figure()
pp.plot([100, 20, 10])

raw_input('Press enter...') # Only the second graph is displayed
$$$

···

On Sunday, May 29, 2011, Eric O LEBIGOT (EOL) > <Eric.Lebigot@...1818...> wrote:

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31731176.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thank you for your response.

Benjamin Root-2 wrote:

What does ion() exactly do?
$$$
from matplotlib import pyplot as pp

pp.plot([10, 20, 50])
pp.draw()

raw_input('Press enter...') # No graph displayed?!!
$$$

Turning interactive mode on also means an implied "show" command, if
needed. The first program can replace draw() with show(). However,
if interactive mode is off, then the python execution pauses. With it
on, python execution will continue.

So, if anything is drawn when interactive mode is off, does one *have* to
use show() at the end? in other words does using a single raw_input() at
the end of the program force the use of the interactive mode for *all*
figures? (Closing all the figures with a simple "enter" is very convenient,
but having a performance penalty for this would not be so nice…).

Yes, if interactive mode is off, and you want to view the figures, you
need show(). No, the raw_input does nothing in either case.

Now, if I understand you correctly, I have another question. I don't
understand anymore what draw() does: in fact, it is not necessary in
interactive mode, and it does not appear to do anything in non-interactive
mode, since show() is really the function that really displays the figures.
So, why does matplotlib offer draw()? what does it really do?

The draw() command is used for some more advanced features such as
animations and widgets, as well as for internal use. I rarely use
draw() in my scripts.

May I suggest reading the FAQ and some of the example scripts on the
website in order to demonstrate the different ways to use mpl?

Ben Root

EOL

PS: Here is an example: the following code does *not* display the first
figure (Matplotlib 1.0.0 on Mac OS X with the GTKAgg backend):

Off the top of my head, this is either a bug that has been fixed, or
is intended behavior. Turning interactive mode on after having made a
figure might be confusing pyplot. Calling show at anytime will
produce the intended behavior. show() is your friend.

···

On Monday, May 30, 2011, Eric O LEBIGOT (EOL) <Eric.Lebigot@...1818...> wrote:

On Sunday, May 29, 2011, Eric O LEBIGOT (EOL) >> <Eric.Lebigot@...1818...> wrote:

$$$
from matplotlib import pyplot as pp

pp.figure()
pp.plot([10, 20, 50])
pp.draw() # Will not be displayed despite the draw()

pp.ion() # Interactive mode on
pp.figure()
pp.plot([100, 20, 10])

raw_input('Press enter...') # Only the second graph is displayed
$$$
--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31731176.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Benjamin Root-2 wrote:

Benjamin Root-2 wrote:
So, if anything is drawn when interactive mode is off, does one *have* to
use show() at the end? in other words does using a single raw_input() at
the end of the program force the use of the interactive mode for *all*
figures? (Closing all the figures with a simple "enter" is very
convenient,
but having a performance penalty for this would not be so nice…).

Yes, if interactive mode is off, and you want to view the figures, you
need show(). No, the raw_input does nothing in either case.

Now, if I understand you correctly, I have another question. I don't
understand anymore what draw() does: in fact, it is not necessary in
interactive mode, and it does not appear to do anything in
non-interactive
mode, since show() is really the function that really displays the
figures.
So, why does matplotlib offer draw()? what does it really do?

The draw() command is used for some more advanced features such as
animations and widgets, as well as for internal use. I rarely use
draw() in my scripts.

Thank you for the follow up.

I wish that Matplotlib provided a mechanism for bypassing show(), because
show() is actually not my friend. :slight_smile: In fact, with show(), I hate having
to close one by one each of the 12 figures that my script creates each time
I run it.

The Matplotlib documentation indeed lists many ways to use Matplotlib.
However, I was trying to get beyond "recipes" and to get a deeper
understanding of what Matplotlib does, so as to avoid wasting too much time
when trying to do something that is not in one of those recipes. Like
stopping a program that was fully or partially in run in non-interactive
mode, without having to use this dreaded show()…

Thank you again for your input. It is good to know the limitations of
Matplotlib. Maybe it is time to suggest the feature I mentioned to the dev
list??

···

On Monday, May 30, 2011, Eric O LEBIGOT (EOL) > <Eric.Lebigot@...1818...> wrote:

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31734191.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Benjamin Root-2 wrote:

Benjamin Root-2 wrote:
So, if anything is drawn when interactive mode is off, does one *have* to
use show() at the end? in other words does using a single raw_input() at
the end of the program force the use of the interactive mode for *all*
figures? (Closing all the figures with a simple "enter" is very
convenient,
but having a performance penalty for this would not be so nice…).

Yes, if interactive mode is off, and you want to view the figures, you
need show(). No, the raw_input does nothing in either case.

Now, if I understand you correctly, I have another question. I don't
understand anymore what draw() does: in fact, it is not necessary in
interactive mode, and it does not appear to do anything in
non-interactive
mode, since show() is really the function that really displays the
figures.
So, why does matplotlib offer draw()? what does it really do?

The draw() command is used for some more advanced features such as
animations and widgets, as well as for internal use. I rarely use
draw() in my scripts.

Thank you for the follow up.

I wish that Matplotlib provided a mechanism for bypassing show(), because
show() is actually not my friend. :slight_smile: In fact, with show(), I hate having
to close one by one each of the 12 figures that my script creates each time
I run it.

The Matplotlib documentation indeed lists many ways to use Matplotlib.
However, I was trying to get beyond "recipes" and to get a deeper
understanding of what Matplotlib does, so as to avoid wasting too much time
when trying to do something that is not in one of those recipes. Like
stopping a program that was fully or partially in run in non-interactive
mode, without having to use this dreaded show()…

Thank you again for your input. It is good to know the limitations of
Matplotlib. Maybe it is time to suggest the feature I mentioned to the dev
list??

I am not sure exactly what feature you are asking for. If you are in
interactive mode, you could setup a key binding to call a function to
close all figures. Another route to go is to take advantage of
subplots and reduce the number of figures you need to have.

Also, it bares repeating. You may be experiencing some bugs with
interactive mode in v1.0.0. Some very important bugfixes were made
wrt interactive mode for the v1.0.1 release. I know the sourceforge
page still points to v1.0.0, that is a problem that I hope to have
fixed later in the next few days.

Ben Root

···

On Monday, May 30, 2011, Eric O LEBIGOT (EOL) <Eric.Lebigot@...1818...> wrote:

On Monday, May 30, 2011, Eric O LEBIGOT (EOL) >> <Eric.Lebigot@...1818...> wrote:

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31734191.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Benjamin Root-2 wrote:

On Monday, May 30, 2011, Eric O LEBIGOT (EOL)

I wish that Matplotlib provided a mechanism for bypassing show(), because
show() is actually not my friend. :slight_smile: In fact, with show(), I hate
having
to close one by one each of the 12 figures that my script creates each
time
I run it.

(…)
stopping a program that was fully or partially in run in non-interactive
mode, without having to use this dreaded show()…
(…)

I am not sure exactly what feature you are asking for. If you are in
interactive mode, you could setup a key binding to call a function to
close all figures. Another route to go is to take advantage of
subplots and reduce the number of figures you need to have.

The keybinding idea is interesting, but the goal is to work in
*non*-interactive mode (for optimization purposes), and the feature I would
love is simply to be able to display graphs in this mode without using
show(). Subplots are unfortunately not an option for me, as each of the
numerous graph must be independent (they are each saved in a specific file).

Benjamin Root-2 wrote:

Also, it bares repeating. You may be experiencing some bugs with
interactive mode in v1.0.0. Some very important bugfixes were made
wrt interactive mode for the v1.0.1 release. I know the sourceforge
page still points to v1.0.0, that is a problem that I hope to have
fixed later in the next few days.

Thanks, I'll definitely check out version 1.0.1. The feature I wish existed
is unfortunately relevant to the *non*-interactive mode.

···

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31734671.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Benjamin Root-2 wrote:

On Monday, May 30, 2011, Eric O LEBIGOT (EOL)

I wish that Matplotlib provided a mechanism for bypassing show(), because
show() is actually not my friend. :slight_smile: In fact, with show(), I hate
having
to close one by one each of the 12 figures that my script creates each
time
I run it.

(…)
stopping a program that was fully or partially in run in non-interactive
mode, without having to use this dreaded show()…
(…)

I am not sure exactly what feature you are asking for. If you are in
interactive mode, you could setup a key binding to call a function to
close all figures. Another route to go is to take advantage of
subplots and reduce the number of figures you need to have.

The keybinding idea is interesting, but the goal is to work in
*non*-interactive mode (for optimization purposes), and the feature I would
love is simply to be able to display graphs in this mode without using
show(). Subplots are unfortunately not an option for me, as each of the
numerous graph must be independent (they are each saved in a specific file).

Is it correct that you want interactive mode, except that you want to control when drawing occurs, for purposes of efficiency? If so, use interactive mode, but instead of using the pyplot interface for the actual plotting, use the OO interface, and call plt.draw() when you want to update a plot. See
http://matplotlib.sourceforge.net/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related
although this does not give precisely the example to match your case.

Eric

···

On 05/30/2011 06:42 AM, Eric O LEBIGOT (EOL) wrote:

Benjamin Root-2 wrote:

Also, it bares repeating. You may be experiencing some bugs with
interactive mode in v1.0.0. Some very important bugfixes were made
wrt interactive mode for the v1.0.1 release. I know the sourceforge
page still points to v1.0.0, that is a problem that I hope to have
fixed later in the next few days.

Thanks, I'll definitely check out version 1.0.1. The feature I wish existed
is unfortunately relevant to the *non*-interactive mode.

efiring wrote:

Is it correct that you want interactive mode, except that you want to
control when drawing occurs, for purposes of efficiency?

Thank you for your interest in this question, Eric!

The goal is to indeed control when drawing occurs, but also to not use
show() (because it cumbersome to have to close umpteen windows so as to
finish a Matplotlib program that opened lots of figures). (I checked the
examples that you referred to)

It looks like Matplotlib forces either to use the interactive mode (possibly
inefficient) or to use show() (possibly cumbersome). I wish that Matplotlib
offers an alternative to this situation, but this looks less and less to be
the case. That's something I would like to suggest to the devs.
:slight_smile:

···

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31735322.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Question: would displaying a figure (or a group of figures), pausing to let you close them, and then continuing to the next figures more along the lines of what you want? That is certainly possible with matplotlib. Since v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1 for certain backends to do this correctly).

Furthermore, I think Eric Firing’s point was that mpl is fully capable of doing what you want. The automatic draws are only done if the calls come through pyplot or pylab and if interactive mode is on. There might be a few minor exceptions to this rule, but those shouldn’t cause significant overhead. If you call the drawing commands directly, then a refresh does not occur until you tell it to with a call to draw(). In pyplot, nearly all drawing commands have as the final step a call to a function called “draw_if_interactive()”. This function does exactly what it says. Therefore, if you want interactive mode, but do not want a refresh after each pyplot command, then don’t use the pyplot commands! Just use the objects’ drawing commands (which is what pyplot calls).

Also, note that matplotlib is hierarchical. You could call directly call draw() on each object you want re-drawn, but you don’t have to. You can give a single call to a parent object that would call draw() for all of its children objects. So, a figure object has (among other things) axes objects as children. An axes object has (among other things) various collection objects from the plotting commands as its children. Maybe a look at some of the animation examples might be a good way to illustrate this. I would suggest looking at the older animation examples on sourceforge where the internals are all laid out.

I hope this is helpful,
Ben Root

···

On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) <Eric.Lebigot@…1818…> wrote:

efiring wrote:

Is it correct that you want interactive mode, except that you want to

control when drawing occurs, for purposes of efficiency?

Thank you for your interest in this question, Eric!

The goal is to indeed control when drawing occurs, but also to not use

show() (because it cumbersome to have to close umpteen windows so as to

finish a Matplotlib program that opened lots of figures). (I checked the

examples that you referred to)

It looks like Matplotlib forces either to use the interactive mode (possibly

inefficient) or to use show() (possibly cumbersome). I wish that Matplotlib

offers an alternative to this situation, but this looks less and less to be

the case. That’s something I would like to suggest to the devs.

:slight_smile:

I really appreciate your continuing this discussion, Ben.

Benjamin Root-2 wrote:

Question: would displaying a figure (or a group of figures), pausing to
let
you close them, and then continuing to the next figures more along the
lines
of what you want? That is certainly possible with matplotlib. Since
v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
for certain backends to do this correctly).

Yeah, the new show() is nice. However, I don't want my users to have to
close the numerous opened figures one by one, even if it is done in 4 times
3 clicks (and, again, it would not be convenient to put the graphs in
subplots). So, what I am really looking for is really: (1) display figures
without having to use show(); and (2) do this efficiently (without automatic
drawing through the interactive mode).

Benjamin Root-2 wrote:

(…) In pyplot, nearly all
drawing commands have as the final step a call to a function called
"draw_if_interactive()".
(…)
You could call directly call
draw() on each object you want re-drawn, but you don't have to. You can
give a single call to a parent object that would call draw() for all of
its
children objects.
(…)

Thank you for these more theoretical explanations, which are interesting.

However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
backend), or 1.0.0 Mac OS X (default backend and GTKAgg). The main problem
is that draw() does unfortunately not draw anything in non-interactive mode
(this happens when there is no show() in the code)! So, with these two
recent version, in *non*-interactive mode, it does not appear that "a
refresh does not occur until you tell it to with a call to draw()", and
things like this. There is no refresh at all, and pyplot.draw() does
display anything (this is illustrated by the last program example I posted).
As far as I can see, theory and practice strongly clash, about the
"refreshing" effect of the draw() command (in non-interactive mode), as I
can't see anything being refreshed or displayed by draw. What is your take
on this?

Thank you for the idea of bypassing pyplot's automatic update in interactive
mode. How is this done? Doing ax.draw(ax.figure.canvas.renderer) raises a
RunTime error with the default Mac OS X backend, and an AttributeError with
the GTKAgg backend. How should the draw() method of Matplotlib objects be
called?

Now that I'm thinking of it, the crux of the problem might be that
pyplot.figure() does *not* open any window, in non-interactive mode (until
show() is called, which I want to avoid). This looks like a bad start if
draw() is to refresh anything… Could this be the main stumbling block? Can
a new window be opened in non-interactive mode (without using show())?

···

On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) < > Eric.Lebigot@...1818...> wrote:

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31738725.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Stop saying you want to avoid show(); let's just figure out how to get to the desired end result. You probably *need* to use show; with 1.0.1 in interactive mode, it will not block. Your script can close the windows; your user doesn't have to do so manually.

It sounds like you are indeed talking about a free-standing script, that is, not involving ipython or other intermediate shell, correct?

Can you come up with a minimal example of what you want it to do, and how you want the user to be able to interact with it? Does the attached script illustrate something roughly like what you are trying to do?

Eric

windows.py (571 Bytes)

···

On 05/30/2011 09:59 PM, Eric O LEBIGOT (EOL) wrote:

I really appreciate your continuing this discussion, Ben.

Benjamin Root-2 wrote:

On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL)< >> Eric.Lebigot@...1818...> wrote:
Question: would displaying a figure (or a group of figures), pausing to
let
you close them, and then continuing to the next figures more along the
lines
of what you want? That is certainly possible with matplotlib. Since
v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
for certain backends to do this correctly).

Yeah, the new show() is nice. However, I don't want my users to have to
close the numerous opened figures one by one, even if it is done in 4 times
3 clicks (and, again, it would not be convenient to put the graphs in
subplots). So, what I am really looking for is really: (1) display figures
without having to use show(); and (2) do this efficiently (without automatic
drawing through the interactive mode).

Benjamin Root-2 wrote:

(…) In pyplot, nearly all
drawing commands have as the final step a call to a function called
"draw_if_interactive()".
(…)
You could call directly call
draw() on each object you want re-drawn, but you don't have to. You can
give a single call to a parent object that would call draw() for all of
its
children objects.
(…)

Thank you for these more theoretical explanations, which are interesting.

However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
backend), or 1.0.0 Mac OS X (default backend and GTKAgg). The main problem
is that draw() does unfortunately not draw anything in non-interactive mode
(this happens when there is no show() in the code)! So, with these two
recent version, in *non*-interactive mode, it does not appear that "a
refresh does not occur until you tell it to with a call to draw()", and
things like this. There is no refresh at all, and pyplot.draw() does
display anything (this is illustrated by the last program example I posted).
As far as I can see, theory and practice strongly clash, about the
"refreshing" effect of the draw() command (in non-interactive mode), as I
can't see anything being refreshed or displayed by draw. What is your take
on this?

Thank you for the idea of bypassing pyplot's automatic update in interactive
mode. How is this done? Doing ax.draw(ax.figure.canvas.renderer) raises a
RunTime error with the default Mac OS X backend, and an AttributeError with
the GTKAgg backend. How should the draw() method of Matplotlib objects be
called?

Now that I'm thinking of it, the crux of the problem might be that
pyplot.figure() does *not* open any window, in non-interactive mode (until
show() is called, which I want to avoid). This looks like a bad start if
draw() is to refresh anything… Could this be the main stumbling block? Can
a new window be opened in non-interactive mode (without using show())?

One-line correction to script attached to last post; so use the one attached here.

windows.py (542 Bytes)

efiring wrote:

Stop saying you want to avoid show(); (…). You probably *need* to use
show; with 1.0.1
in interactive mode, it will not block. Your script can close the
windows; your user doesn't have to do so manually.

You are right: your script shows that the latest (1.0.1) show() is great, as
it is non-blocking in interactive mode (except with the macosx backend).
(It is the pre-1.0.1 blocking show() that was not a solution.)

efiring wrote:

It sounds like you are indeed talking about a free-standing script, that
is, not involving ipython or other intermediate shell, correct?

Correct.

efiring wrote:

Does the attached
script illustrate something roughly like what you are trying to do?

Yes, it does, thanks. Just a detail: since the interactive mode is on, the
plt.draw()s in the second part are not necessary, are they?

So, to summarize, the latest 1.0.1 show() does the actual drawing (not
draw()), is non-blocking in interactive mode, and can be called multiple
times. This is both convenient (no need to manually close umpteen windows
one by one), and efficient (non interactive mode can be used up until show()
is called). Thus, the practical side of the problem is closed: thanks!

I have been asking these questions because I have been using and teaching
(Python and) Matplotlib for 3 years, now, to students who use a variety of
OSes, so I wanted to get things straight.

On the "theoretical" side, draw() is actually rarely used for drawing or
refreshing simple figures (including common non-animated figures), but is
more for "some more advanced features such as animations and widgets, as
well as for internal use.", as Ben was writing, right? And show() is really
the function that commonly does the actual display or refresh, right? If
this is correct, I will be done with my questions.
:slight_smile:

···

--
View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31739359.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

efiring wrote:

Stop saying you want to avoid show(); (…). You probably *need* to use
show; with 1.0.1

The above was wrong--see below. If you start with interactive mode on, you do not need show at all. In non-interactive mode, you do need show.

in interactive mode, it will not block. Your script can close the
windows; your user doesn't have to do so manually.

You are right: your script shows that the latest (1.0.1) show() is great, as
it is non-blocking in interactive mode (except with the macosx backend).
(It is the pre-1.0.1 blocking show() that was not a solution.)

efiring wrote:

It sounds like you are indeed talking about a free-standing script, that
is, not involving ipython or other intermediate shell, correct?

Correct.

efiring wrote:

Does the attached
script illustrate something roughly like what you are trying to do?

Yes, it does, thanks. Just a detail: since the interactive mode is on, the
plt.draw()s in the second part are not necessary, are they?

Not a detail: you do need the draw if you are not ending with a pyplot function, as opposed to an object method. You could just use the pyplot function, plt.plot(), instead of the method, ax.plot(), etc., which would call the draw automatically.

Now, you may find that everything works the same if you eliminate the first draw in my example; that is because the plt.figure() call has put a draw request in to the gui toolkit, and the toolkit is not executing it right away. Don't rely on this, however; if you are using the object methods, call draw when you want the figure to be refreshed.

So, to summarize, the latest 1.0.1 show() does the actual drawing (not
draw()), is non-blocking in interactive mode, and can be called multiple
times. This is both convenient (no need to manually close umpteen windows
one by one), and efficient (non interactive mode can be used up until show()
is called). Thus, the practical side of the problem is closed: thanks!

Not quite. Draw() ensures that everything is up to date; show() is not a direct substitute.

In my example script, I should have put the call to plt.ion() *before* all other pyplot calls. If you do that, then you actually don't need the show() at all, because the the initial call to plt.figure() in interactive mode displays the figure.

I have been asking these questions because I have been using and teaching
(Python and) Matplotlib for 3 years, now, to students who use a variety of
OSes, so I wanted to get things straight.

On the "theoretical" side, draw() is actually rarely used for drawing or
refreshing simple figures (including common non-animated figures), but is
more for "some more advanced features such as animations and widgets, as
well as for internal use.", as Ben was writing, right? And show() is really
the function that commonly does the actual display or refresh, right? If
this is correct, I will be done with my questions.
:slight_smile:

No, if you use object methods rather than the pyplot interface, then you need to use draw(). For example, if you try changing the last draw() in my example to a show(), the new line will not be added.

Eric

···

On 05/30/2011 11:42 PM, Eric O LEBIGOT (EOL) wrote:

Thank you for these precisions.

I think I'm starting to see more clearly what the
interactive/non-interactive modes do with pyplot commands (plot(), draw(),
show(),…), and with draw() methods.

There is only one thing that I'm not sure about: if we look at your script
and leave the ion() were you left it, shouldn't an ax.draw() be called just
before the ion()? (I indeed understand from your last post that one "should
not rely" on "pyplot.figure()" sending a delayed draw() request to the GUI.)

So, to summarize the whole discussion:

* Interactive mode:

- Graph elements plotted with *pyplot* commands (not Matplotlib object
methods) are displayed without the need to use draw() or show().

- However, plots done through Matplotlib objects (like Axes) are normally
not displayed (even though they may be, with some backends). The actual
display of such plots is done through their draw() method (or possibly
pyplot.draw()). This feature might be used for optimization purposes (a
graph can be refreshed on screen once even though multiple updates were
performed on it through Matplotlib object method calls).

- show(), if used, is non-blocking. It displays everything that was drawn()
(for instance figures that were created in non-interactive mode). Things
that were not drawn() might be displayed by some backends, but one should
not rely on this.

* Non-interactive mode

- No figure or graph is displayed and/or refreshed automatically. This is
useful for optimization purposes, when a graph is updated many times before
it reaches its final state (modification of some elements, like changing a
color, etc.).

- show() displays all the drawn() elements and is blocking. It is possible
to switch temporarily to interactive mode in order to make it non-blocking.

=> Is this correct? are there other issues that could be important for
students (and myself!) to grasp so that they use Matplotlib as best as
possible?

···


View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31748057.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

PS: One could add to the non-interactive mode part that "pyplot.draw()" has
the same effect as drawing() everything (normally, this does not display
anything, but is necessary so that show() displays the drawn() elements).
Right?

···


View this message in context: http://old.nabble.com/Exact-semantics-of-ion()---tp31728909p31748078.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst

Eric, Ben,

See if the section "What is interactive mode" makes sense to you. I have just added it to a feature branch (which includes some other faq madifications, mainly moving the backend section from installation to usage), but have not yet generated a pull request. It doesn't go into every detail, or into the underlying machinery. It is intended to provide just enough understanding to clear up user-level confusion about interactive mode, show, and draw, and let most relatively new users get on with their work.

Eric

Eric,

I see where you are going with this, and this is valuable information
to include in the docs. However, the interactive mode and backend info
doesn't seem to fit properly with everything else on the page. I am
not sure where to put them yet, but I will see if I can take a deeper
look tomorrow. I also already noticed some other wording issues in
some other parts of that page.

Ben Root

···

On Saturday, June 4, 2011, Eric Firing <efiring@...202...> wrote:

https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst

Eric, Ben,

See if the section "What is interactive mode" makes sense to you. I have just added it to a feature branch (which includes some other faq madifications, mainly moving the backend section from installation to usage), but have not yet generated a pull request. It doesn't go into every detail, or into the underlying machinery. It is intended to provide just enough understanding to clear up user-level confusion about interactive mode, show, and draw, and let most relatively new users get on with their work.

Eric

https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst

Eric, Ben,

See if the section "What is interactive mode" makes sense to you. I have just added it to a feature branch (which includes some other faq madifications, mainly moving the backend section from installation to usage), but have not yet generated a pull request. It doesn't go into every detail, or into the underlying machinery. It is intended to provide just enough understanding to clear up user-level confusion about interactive mode, show, and draw, and let most relatively new users get on with their work.

Eric

Eric,

I see where you are going with this, and this is valuable information
to include in the docs. However, the interactive mode and backend info
doesn't seem to fit properly with everything else on the page. I am

I don't see why not. A FAQ is a place for answers to questions, and this is the usage section of the FAQ, so I don't see any inherent reason why information about backends and interactive mode, both of which involve mpl usage, can't go there. There may be better places, to which the FAQ could refer, but I think the FAQ is better than nothing. I moved the backend piece from the installation part of the FAQ, where it *really* didn't belong. (And the remaining installation part is also an out-of-date worm jar.)

not sure where to put them yet, but I will see if I can take a deeper
look tomorrow. I also already noticed some other wording issues in
some other parts of that page.

Ben Root

What you will also find is that the section users/shell.rst, which threw Eric L for a loop in the first place, badly needs updating, and overlaps with what I was trying to do in the FAQ. As Eric also points out, a section with more detail would probably be good somewhere; I was thinking of putting that in the FAQ also, at least as a first step.

My github branch now includes a changeset with augmented docstrings for show and draw.

Eric

···

On 06/07/2011 11:46 AM, Benjamin Root wrote:

On Saturday, June 4, 2011, Eric Firing<efiring@...202...> wrote: