Re: [Matplotlib-users] Mac OSX backend
On Sat, Nov 13, 2010 at 7:58 PM, Michiel de Hoon 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? > > 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 -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
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 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. -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
Thanks for your reply.
--- On Sat, 11/13/10, Eric Firing wrote:
> 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(40)
y = x + numpy.random.random(40)
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.
--
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
On Sat, Nov 13, 2010 at 12:06 PM, Eric Firing wrote: > On 11/13/2010 06:16 AM, Michiel de Hoon wrote: > > --- On Sat, 11/13/10, John Hunter 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. > > > > 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 -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
On 11/13/2010 06:16 AM, Michiel de Hoon wrote: > --- On Sat, 11/13/10, John Hunter 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. > -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
--- On Sat, 11/13/10, John Hunter 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. > 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. -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
On Sat, Nov 13, 2010 at 9:23 AM, Michiel de Hoon 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. 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? -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
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 wrote:
> From: John Hunter
> Subject: Re: [Matplotlib-users] Mac OSX backend
> To: "Michiel de Hoon"
> Cc: "mdekauwe" , matplotlib-users@lists.sourceforge.net
> Date: Saturday, November 13, 2010, 9:22 AM
> On Sat, Nov 13, 2010 at 7:46 AM,
> Michiel de Hoon
> 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
>
--
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
On Sat, Nov 13, 2010 at 7:46 AM, Michiel de Hoon 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
--
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Mac OSX backend
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 wrote: > From: John Hunter > Subject: Re: [Matplotlib-users] Mac OSX backend > To: "Michiel de Hoon" > Cc: "mdekauwe" , matplotlib-users@lists.sourceforge.net > Date: Friday, November 12, 2010, 9:06 AM > On Thu, Nov 11, 2010 at 7:32 PM, > Michiel de Hoon > 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 > -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Backgroundcolor for text
I wasn't able to replicate this bug with the MacOS backend. --Michiel On Sat Nov 13th, 2010 1:15 AM EST Jae-Joon Lee wrote: >I cannot reproduce this with agg, ps and pdf backend. >Maybe this bug is specific to the Mac oS X backend? > >Regards, > >-JJ > > >On Sat, Nov 13, 2010 at 5:19 AM, Bror Jonsson wrote: >> >> Dear all, >> >> I must be doing something wrong, but it seems like the backgroundcolor >> statement for text just stopped working. I am using matplotlib 1.0.0 with >> MacOSX as backend on two different machines. If I run >> >> ipython -pylab >> >> text(0,0,'Kalle',backgroundcolor='0.6') >> >> I get this result: >> >> >> >> (The problem is that the text color switches to pale grey). This worked fine >> before. Does anyone else get this problem, and do you have any idea about >> how to trouble shoot it? >> >> Regards, >> >> Bror Jonsson >> -- >> 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 >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> > >-- >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 >https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
