matplotlib-users Mailing List for matplotlib

On 11/13/2010 06:16 AM, Michiel de Hoon wrote:
> --- On Sat, 11/13/10, John Hunter<jd...@gm...> 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.
>

--- On Sat, 11/13/10, John Hunter <jd...@gm...> 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.
 

On Sat, Nov 13, 2010 at 9:23 AM, Michiel de Hoon <mjl...@ya...> 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?

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 <jd...@gm...> wrote:
> From: John Hunter <jd...@gm...>
> Subject: Re: [Matplotlib-users] Mac OSX backend
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "mdekauwe" <mde...@gm...>, mat...@li...
> Date: Saturday, November 13, 2010, 9:22 AM
> On Sat, Nov 13, 2010 at 7:46 AM,
> Michiel de Hoon <mjl...@ya...>
> 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
> 
 

On Sat, Nov 13, 2010 at 7:46 AM, Michiel de Hoon <mjl...@ya...> 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

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 <jd...@gm...> wrote:
> From: John Hunter <jd...@gm...>
> Subject: Re: [Matplotlib-users] Mac OSX backend
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "mdekauwe" <mde...@gm...>, mat...@li...
> Date: Friday, November 12, 2010, 9:06 AM
> On Thu, Nov 11, 2010 at 7:32 PM,
> Michiel de Hoon <mjl...@ya...>
> 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
> 
 

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 <br...@bi...> 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
>> Mat...@li...
>> 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
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
 

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 <br...@bi...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

With axisartist toolkit, no.
I may add a simple wrapper around matplotlit's original formatter classes.
Regards,
-JJ
On Thu, Nov 11, 2010 at 11:17 PM, Stefan Mauerberger
<ste...@mn...> wrote:
> Hi JJ,
>
> thanks a lot for your Answer. Now I have understand how this works and
> created my one formatter:
>
> class MyFormatter(object):
>  def __init__(self, fmt='$%f$'):
>      self.fmt = fmt
>  def __call__(self, direction, factor, values):
>      return [self.fmt % v for v in values]
>
> Is there something like this already in Matplotlib? I looked into
> axisartist but can not find anything similar.
>
> Regards
>
> Stefan
>
>
> On Thu, 2010年11月11日 at 09:38 +0900, Jae-Joon Lee wrote:
>> How do you want your ticklabels formatted?
>>
>> If axisartist does not provide a formatter that fits your need, you
>> can create a custom formatter.
>> Formatter for axisartist can be any callable object with following signature.
>>
>> def Formatter(direction, factor, values):
>>   # ...
>>   return list_of_string_that corresponds_to_values
>>
>> You may ignore direction and factor parameters for now.
>> For example,
>>
>> class MyFormatter(object):
>>   def __call__(self, direction, factor, values):
>>     _fmt = "$%.1f$"
>>     return [_fmt % v for v in values]
>>
>> then you could do
>>
>> grid_helper = floating_axes.GridHelperCurveLinear( tr, extremes=( 1, 2,
>> 1000, 2000 ), tick_formatter1 = None, tick_formatter2 = MyFormatter() )
>>
>> Regards,
>>
>> -JJ
>>
>>
>> On Wed, Nov 10, 2010 at 10:17 PM, Stefan Mauerberger
>> <ste...@mn...> wrote:
>> > Hello everyone,
>> >
>> > I have a question regarding the formatting of ticks in a curved
>> > coordinate system. To create my plots I am useing the
>> > mpl_toolkits.axisartist.floating_axes.GridHelperCurveLinear() function.
>> > This works quite well but I have difficulties with formatting the axis.
>> > I am working in a polar coordinate system. To format the longitudinal
>> > axis I found the function
>> > mpl_toolkits.axisartist.angle_helper.FormatterDMS() and it works good.
>> > But I want to chance the formatting of the radius too. For this I need
>> > to pass something to the kwargs tick_formatter2 of the function
>> > GridHelperCurveLinear but I do not know what.
>> >
>> > Could you give me some advice?
>> >
>> > Regards
>> >
>> > Stefan
>> >
>> > Here is the code I use:
>> >
>> > import matplotlib.pyplot as plt
>> > import mpl_toolkits.axisartist.floating_axes as floating_axes
>> > from  matplotlib.projections import PolarAxes
>> >
>> > fig = plt.figure()
>> >
>> > tr = PolarAxes.PolarTransform()
>> >
>> > grid_helper = floating_axes.GridHelperCurveLinear( tr, extremes=( 1, 2,
>> > 1000, 2000 ), tick_formatter1 = None, tick_formatter2 = None )
>> >
>> > ax1 = floating_axes.FloatingSubplot( fig, 111, grid_helper=grid_helper )
>> >
>> > fig.add_subplot( ax1 )
>> >
>> > ax1.grid( True )
>> >
>> > plt.show()
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> > David G. Thomson, author of the best-selling book "Blueprint to a
>> > Billion" shares his insights and actions to help propel your
>> > business during the next growth cycle. Listen Now!
>> > http://p.sf.net/sfu/SAP-dev2dev
>> > _______________________________________________
>> > Matplotlib-users mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> >
>>
>
>