Mac OSX backend

Community matplotlib-users
1

Hi,
I have my backend set up in my .matplotlib/matplotlibrc file as:

backend : MacOSX

However if I run a script which does multiple plots and I don't ask the
script to display the plots (i.e. not imshow()), I still get blank windows
popping up. Does anyone else have this problem? Any solutions?

thanks,

Martin

···

--
View this message in context: http://old.nabble.com/Mac-OSX-backend-tp30188676p30188676.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

2

Please post the script that is giving you problems

JDH

···

On Nov 11, 2010, at 4:15 AM, mdekauwe <mdekauwe@...287...> wrote:

Hi,
I have my backend set up in my .matplotlib/matplotlibrc file as:

backend : MacOSX

However if I run a script which does multiple plots and I don't ask the
script to display the plots (i.e. not imshow()), I still get blank windows
popping up. Does anyone else have this problem? Any solutions?

3

It isn't any one script, if you did

import numpy as np
import matplotlib.pyplot as plt
x = np.arange(10)
for i in xrange(10):
    plt.plot(x)
    plt.savefig('x.png')

it pops up the plot window even though I didn't ask it to. I don't get this
functionality on a non mac system. So I wonder if it relates to the choice
of backend

thanks

John Hunter-4 wrote:

···

On Nov 11, 2010, at 4:15 AM, mdekauwe <mdekauwe@...287...> wrote:

Hi,
I have my backend set up in my .matplotlib/matplotlibrc file as:

backend : MacOSX

However if I run a script which does multiple plots and I don't ask the
script to display the plots (i.e. not imshow()), I still get blank
windows
popping up. Does anyone else have this problem? Any solutions?

Please post the script that is giving you problems

JDH

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

--
View this message in context: http://old.nabble.com/Mac-OSX-backend-tp30188676p30189599.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

4

I see -- so it is raising the window even w/o show. This is a bug,
but a minor one. I suggest at the top of your script (before pyplot
import) doing

import matplotlib
matplotlib.use('agg')

if you only want to save hardcopy png -- macosx may not support
offline rendering.

···

On Thu, Nov 11, 2010 at 6:32 AM, mdekauwe <mdekauwe@...287...> wrote:

It isn't any one script, if you did

import numpy as np
import matplotlib.pyplot as plt
x = np.arange(10)
for i in xrange(10):
plt.plot(x)
plt.savefig('x.png')

it pops up the plot window even though I didn't ask it to. I don't get this
functionality on a non mac system. So I wonder if it relates to the choice
of backend

5

OK thanks so perhaps I should also try another backend then? What do other
mac users opt for?

ps. that works by the way.

John Hunter-4 wrote:

···

On Thu, Nov 11, 2010 at 6:32 AM, mdekauwe <mdekauwe@...287...> wrote:

It isn't any one script, if you did

import numpy as np
import matplotlib.pyplot as plt
x = np.arange(10)
for i in xrange(10):
plt.plot(x)
plt.savefig('x.png')

it pops up the plot window even though I didn't ask it to. I don't get
this
functionality on a non mac system. So I wonder if it relates to the
choice
of backend

I see -- so it is raising the window even w/o show. This is a bug,
but a minor one. I suggest at the top of your script (before pyplot
import) doing

import matplotlib
matplotlib.use('agg')

if you only want to save hardcopy png -- macosx may not support
offline rendering.

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

--
View this message in context: http://old.nabble.com/Mac-OSX-backend-tp30188676p30189678.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

6

For this example, I am finding the exact same behavior with the Mac OS X backend as with the gtkcairo and gtkagg backends (on Mac OS X and Cygwin). If this is a bug, then which backend can we use as an example of the correct behavior for this code?

Best,
--Michiel

···

--- On Thu, 11/11/10, John Hunter <jdh2358@...287...> wrote:

From: John Hunter <jdh2358@...287...>
Subject: Re: [Matplotlib-users] Mac OSX backend
To: "mdekauwe" <mdekauwe@...287...>
Cc: matplotlib-users@lists.sourceforge.net, "Michiel de Hoon" <mjldehoon@...9...>
Date: Thursday, November 11, 2010, 7:39 AM
On Thu, Nov 11, 2010 at 6:32 AM, > mdekauwe <mdekauwe@...287...> > wrote:
>
> It isn't any one script, if you did
>
> import numpy as np
> import matplotlib.pyplot as plt
> x = np.arange(10)
> for i in xrange(10):
> plt.plot(x)
> plt.savefig('x.png')
>
> it pops up the plot window even though I didn't ask it
to. I don't get this
> functionality on a non mac system. So I wonder if it
relates to the choice
> of backend

I see -- so it is raising the window even w/o show.
This is a bug,
but a minor one. I suggest at the top of your script
(before pyplot
import) doing

import matplotlib
matplotlib.use('agg')

if you only want to save hardcopy png -- macosx may not
support
offline rendering.

7

On a quick test, the following script

  import matplotlib.pyplot as plt
  for i in range(4):
      fig = plt.figure()

(no show) run with -dTkAGG and -dGTKAgg, does not raise a figure
window in svn HEAD. I thought the OP was complaining that the figure
was being raised w/o a call to show in macosx (don't have ready access
to test on an osx box right now)

JDH

···

On Thu, Nov 11, 2010 at 7:32 PM, Michiel de Hoon <mjldehoon@...9...> wrote:

For this example, I am finding the exact same behavior with the Mac OS X backend as with the gtkcairo and gtkagg backends (on Mac OS X and Cygwin). If this is a bug, then which backend can we use as an example of the correct behavior for this code?

8

OK, thanks. With your example, I see a difference between the Mac OS X backend and the TKAgg/GtkAgg backend but only if interactive is False in matplotlibrc. If interactive is True, both the Mac OS X backend and the TkAgg backend open windows. Is this really the desired behavior? It seems counterintuitive that such a global parameter can determine whether a figure is opened or not.

While we're on the topic, is this interactive parameter still needed in matplotlib? In my understanding, in older versions of matplotlib, interactive=False could significantly speed up some plots. But are there still any such cases with the current organization of the drawing code in matplotlib?

Thanks,
--Michiel.

···

--- On Fri, 11/12/10, John Hunter <jdh2358@...287...> wrote:

From: John Hunter <jdh2358@...287...>
Subject: Re: [Matplotlib-users] Mac OSX backend
To: "Michiel de Hoon" <mjldehoon@...9...>
Cc: "mdekauwe" <mdekauwe@...287...>, matplotlib-users@...504...et
Date: Friday, November 12, 2010, 9:06 AM
On Thu, Nov 11, 2010 at 7:32 PM, > Michiel de Hoon <mjldehoon@...9...> > wrote:
> For this example, I am finding the exact same behavior
with the Mac OS X backend as with the gtkcairo and gtkagg
backends (on Mac OS X and Cygwin). If this is a bug, then
which backend can we use as an example of the correct
behavior for this code?

On a quick test, the following script

import matplotlib.pyplot as plt
for i in range(4):
fig = plt.figure()

(no show) run with -dTkAGG and -dGTKAgg, does not raise a
figure
window in svn HEAD. I thought the OP was complaining
that the figure
was being raised w/o a call to show in macosx (don't have
ready access
to test on an osx box right now)

JDH

9

Yes, this is the desired behavior. The interactive : True parameter
is useful when working interactively from the shell, when want to do

  plt.figure()
  plt.plot([1,2,3])
  plt.xlabel('a label')

and have the figure show up on the figure call and update on the plot
and xlabel call. This is most definitely not what you want to do in a
script, because you don't want to pay for the draw until the end (when
a call to show is made). This is discussed at

  http://matplotlib.sourceforge.net/users/shell.html

JDH

···

On Sat, Nov 13, 2010 at 7:46 AM, Michiel de Hoon <mjldehoon@...9...> wrote:

OK, thanks. With your example, I see a difference between the Mac OS X backend and the TKAgg/GtkAgg backend but only if interactive is False in matplotlibrc. If interactive is True, both the Mac OS X backend and the TkAgg backend open windows. Is this really the desired behavior? It seems counterintuitive that such a global parameter can determine whether a figure is opened or not.

While we're on the topic, is this interactive parameter still needed in matplotlib? In my understanding, in older versions of matplotlib, interactive=False could significantly speed up some plots. But are there still any such cases with the current organization of the drawing code in matplotlib?

10

Thanks for your reply.
But nowadays drawing is done through draw_idle, so we don't trigger additional drawing even if interactive is True. In your example, if run as a script, there is no drawing until a call to show() is made, regardless of whether interactive is True or False.

Best,
--Michiel.

···

--- On Sat, 11/13/10, John Hunter <jdh2358@...287...> wrote:

From: John Hunter <jdh2358@...287...>
Subject: Re: [Matplotlib-users] Mac OSX backend
To: "Michiel de Hoon" <mjldehoon@...9...>
Cc: "mdekauwe" <mdekauwe@...287...>, matplotlib-users@...504...et
Date: Saturday, November 13, 2010, 9:22 AM
On Sat, Nov 13, 2010 at 7:46 AM, > Michiel de Hoon <mjldehoon@...9...> > wrote:
> OK, thanks. With your example, I see a difference
between the Mac OS X backend and the TKAgg/GtkAgg backend
but only if interactive is False in matplotlibrc. If
interactive is True, both the Mac OS X backend and the TkAgg
backend open windows. Is this really the desired behavior?
It seems counterintuitive that such a global parameter can
determine whether a figure is opened or not.
>
> While we're on the topic, is this interactive
parameter still needed in matplotlib? In my understanding,
in older versions of matplotlib, interactive=False could
significantly speed up some plots. But are there still any
such cases with the current organization of the drawing code
in matplotlib?

Yes, this is the desired behavior. The interactive :
True parameter
is useful when working interactively from the shell, when
want to do

plt.figure()
plt.plot([1,2,3])
plt.xlabel('a label')

and have the figure show up on the figure call and update
on the plot
and xlabel call. This is most definitely not what you
want to do in a
script, because you don't want to pay for the draw until
the end (when
a call to show is made). This is discussed at

http://matplotlib.sourceforge.net/users/shell.html

JDH

11

I see. I wasn't appreciating your point and had neglected to consider
the idle drawing handling. Are we sure this will save us. Ie if we
have a scirpt like

  # some plotting commands
  ...

  # some expensive non GUI computation
  ...

  # some update to plot above
  ...

Would we not run the risk that the GUI is idle in the non GUI
computation and therefore trigger a draw in it's thread, and then do
redraws again after the update code? I did run some tests and
confirmed what you said, that with the idle handling the repeat calls
to pyplot commands did not generate extra calls (except in qtagg in
which I suspect the idle handling has not been implemented.

Are you proposing that we can get rid of the interactive setting
entirely, always call draw on pyplot commands, and let the idle
handler save us from doing repeated draws?

···

On Sat, Nov 13, 2010 at 9:23 AM, Michiel de Hoon <mjldehoon@...9...> wrote:

Thanks for your reply.
But nowadays drawing is done through draw_idle, so we don't trigger additional drawing even if interactive is True. In your example, if run as a script, there is no drawing until a call to show() is made, regardless of whether interactive is True or False.

12

Ie if we have a script like

# some plotting commands
...

# some expensive non GUI computation
...

# some update to plot above
...

Would we not run the risk that the GUI is idle in the non
GUI computation and therefore trigger a draw in it's thread,
and then do redraws again after the update code?

In the MacOSX backend, everything is single-threaded, so this won't occur.

I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the "idle" refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing.

Are you proposing that we can get rid of the interactive setting
entirely, always call draw on pyplot commands, and let the
idle handler save us from doing repeated draws?

Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug.

Best,
--Michiel.

···

--- On Sat, 11/13/10, John Hunter <jdh2358@...287...> wrote:

13

Ie if we have a script like

   # some plotting commands
   ...

   # some expensive non GUI computation
   ...

   # some update to plot above
   ...

Would we not run the risk that the GUI is idle in the non
GUI computation and therefore trigger a draw in it's thread,
and then do redraws again after the update code?

In the MacOSX backend, everything is single-threaded, so this won't occur.

I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the "idle" refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing.

In the gtk backend, draw_idle calls gobject.idle_add Overview — PyGObject

Thus, "idle" means the gui event loop has no higher priority events. Is this condition reached only at the end of the script?

Are you proposing that we can get rid of the interactive setting
entirely, always call draw on pyplot commands, and let the
idle handler save us from doing repeated draws?

Reminder: the interactive setting controls draw_if_interactive, which is what we are talking about here, but also whether or not show() blocks. So we may not need draw_if_interactive, but unless we can dispense with show entirely, we will still need an interactive setting.

Returning to the issue raised by the OP, however, the question is whether the present MacOSX behavior (windows pop up) or the non-MacOSX behavior (they don't in non-interactive mode until/unless show() is called) is what we really want. It seems to me that we should preserve some way of getting this second behavior.

Eric

···

On 11/13/2010 06:16 AM, Michiel de Hoon wrote:

--- On Sat, 11/13/10, John Hunter<jdh2358@...287...> wrote:

Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug.

Best,
--Michiel.

14

I would like to cast a vote of support for the “interactive=False” setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow. When I want to see all my figures, I will call show() when I am good and ready. And just as I often do work on my netbook, I also do plenty of work on my workstation which sports a large screen. In many cases on that machine, I would like to see my figures while I am working on them, and having an easy option to turn that on and off is valuable to me.

interactive : False was one of several reasons why I switched from Matlab to matplotlib.

On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here.

Ben Root

···

On Sat, Nov 13, 2010 at 12:06 PM, Eric Firing <efiring@…202…> wrote:

On 11/13/2010 06:16 AM, Michiel de Hoon wrote:

— On Sat, 11/13/10, John Hunter<jdh2358@…287…> wrote:

Ie if we have a script like

some plotting commands

…

some expensive non GUI computation

…

some update to plot above

…

Would we not run the risk that the GUI is idle in the non

GUI computation and therefore trigger a draw in it’s thread,

and then do redraws again after the update code?

In the MacOSX backend, everything is single-threaded, so this won’t occur.

I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the “idle” refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing.

In the gtk backend, draw_idle calls gobject.idle_add

http://www.pygtk.org/pygtk2reference/gobject-functions.html#function-gobject–idle-add

Thus, “idle” means the gui event loop has no higher priority events. Is

this condition reached only at the end of the script?

Are you proposing that we can get rid of the interactive setting

entirely, always call draw on pyplot commands, and let the

idle handler save us from doing repeated draws?

Reminder: the interactive setting controls draw_if_interactive, which is

what we are talking about here, but also whether or not show() blocks.

So we may not need draw_if_interactive, but unless we can dispense with

show entirely, we will still need an interactive setting.

Returning to the issue raised by the OP, however, the question is

whether the present MacOSX behavior (windows pop up) or the non-MacOSX

behavior (they don’t in non-interactive mode until/unless show() is

called) is what we really want. It seems to me that we should preserve

some way of getting this second behavior.

Eric

Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug.

Best,

–Michiel.

15

Thanks for your reply.

In the gtk backend, draw_idle calls gobject.idle_add

Thus, "idle" means the gui event loop has no higher
priority events. Is
this condition reached only at the end of the script?

With Python, there is only one thread (running both Python and the GUI). So the GUI event loop won't start until the end of the script, so there is no inadvertent redrawing regardless of interactive being True or False.
With ipython, I am not sure if they are using one thread, or one thread for Python and one thread for the GUI. But in practice, in ipython I also don't find any evidence of inadvertent redrawing. For example, this script:

import matplotlib
matplotlib.use("gtkagg")
import matplotlib.pyplot as plt
import numpy

x = numpy.random.random(400000)
y = x + numpy.random.random(400000)
plt.figure()
plt.hexbin(x, y, gridsize=300)
for i in range(1000):
    plt.xlabel('a label')
plt.show()

both with python and ipython take an equal amount of time regardless of interactive being True or False. If there were any redrawing after each call to plt.xlabel, this script would take forever.

Reminder: the interactive setting controls
draw_if_interactive, which is
what we are talking about here, but also whether or not
show() blocks.
So we may not need draw_if_interactive, but unless we can
dispense with
show entirely, we will still need an interactive setting.

If matplotlib were always interactive, then I don't see a good reason for non-blocking show().

Returning to the issue raised by the OP, however, the
question is
whether the present MacOSX behavior (windows pop up) or the
non-MacOSX
behavior (they don't in non-interactive mode until/unless
show() is
called) is what we really want. It seems to me that
we should preserve
some way of getting this second behavior.

I agree. For example, if a user wants to make a figure for the sole purpose of creating a PNG file, there should be a way to do this without the figure popping up as a window.

--Michiel.

···

--- On Sat, 11/13/10, Eric Firing <efiring@...202...> wrote:

16

Thanks for your reply.
Regarding your first question, how exactly does it disrupt your workflow? Is it because the drawing takes too much time? Or because the focus switches from the terminal window to the figure window? Or because the figure takes up screen space?
Regarding the OP, my understanding is that the original issue is that with interactive=False, the MacOSX backend pops up a window while the other backends do not. It doesn’t make a difference in running time, but anyway the different backends should behave the same way, so something needs to be done here.
–Michiel.

···

— On Sat, 11/13/10, Benjamin Root <ben.root@…1304…> wrote:

I would like to cast a vote of support for the “interactive=False” setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow.

…
On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx
backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here.

17

It is partly because the focus switches from the terminal window to the figure window (at least, at fiirst it does), but mostly because there isn’t enough screen real estate for both to co-exist. Therefore, I would be alt-tabbing a lot if I am in interactive mode.

Anyway, I mostly work from the perspective of running scripts and larger programs to generate publication quality figures and to perform data analyses. My focus is not on messing around with my figures. The only time I am doing that is when I am developing and testing a new script or feature, in which case I might go into interactive mode to figure out what settings and such make my figures look nice, or maybe not.

It is nice to have the option to suit my needs. More often than not, I am in non-interactive mode. I see no reason to remove this feature as it puts matplotlib ahead of other systems like Matlab. Choice is a good thing…

Ben Root

···

On Sat, Nov 13, 2010 at 7:58 PM, Michiel de Hoon <mjldehoon@…9…> wrote:

Thanks for your reply.

Regarding your first question, how exactly does it disrupt your workflow? Is it because the drawing takes too much time? Or because the focus switches from the terminal window to the figure window? Or because the figure takes up screen space?