matplotlib-users Mailing List for matplotlib

barh takes an optional argument "log". set this True (or you may set
"left" with some meaningful value, other than 0)
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.barh
-JJ
On Wed, Oct 14, 2009 at 4:30 PM, Donovan Parks <don...@gm...> wrote:
> Hello,
>
> I've encountered two bugs recently in matplotlib. I am hoping someone
> can tell me if these are known issues and if any workarounds have been
> proposed. The bug occurs for horizontal bar chart where the x-axis has
> a log scale:
>
> from pylab import *
>
> val = 3+10*rand(5)   # the bar lengths
> pos = arange(5)+.5  # the bar centers on the y axis
>
> axes = subplot(111)
> axes.barh(pos,val, align='center')
> axes.set_xscale('log')
>
> for a in axes.yaxis.majorTicks:
> a.tick1On=False
> a.tick2On=False
>
> for a in axes.xaxis.majorTicks:
> a.tick1On=True
> a.tick2On=False
>
> for loc, spine in axes.spines.iteritems():
> if loc in ['left','right','top']:
>   spine.set_color('none')
>
> show()
>
> If you run this code, you will see that only the end caps of the
> horizontal bars are drawn. Furthermore, tick marks appear at the top
> of the plot (despite explicitly turning them off). If a linear scale
> is used the plot is generated as expected. The issue with tick marks
> appearing incorrectly with log axes appears to occur with many types
> of graphs (well, at least the three I tried).
>
> Can anyone suggest how I might plot a bar chart with a log scale? Is
> there any other way I might force the tick marks at the top to not be
> drawn?
>
> Thanks for any and all help.
>
> Cheers,
> Donovan
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

It is possible but not so fancy.
Regards,
-JJ
clf()
ax1= subplot(111)
ax2= ax1.twiny()
ax2.set_xlim(0,10)
def report_ax1ax2(x2, y2):
 # x2, y2 : data coordinate in ax2
 xy_pixel = ax2.transData.transform_point((x2,y2))
 x1, y1 = ax1.transData.inverted().transform_point(xy_pixel)
 return "x1=%f x2=%f y=%f" % (x1, x2, y2)
ax2.format_coord = report_ax1ax2
On Thu, Oct 15, 2009 at 5:58 AM, LB <bra...@gm...> wrote:
>  Hi,
>
>
> I'm using the twiny fonction to plot two functions on the same axes.
> I would like to have both informations displayed on the navigation bar.
> Now, I have :
>  pan/zoom : x=220, y=80
>
> Is-it possible to customize the toolbar in order to have
>  pan/zoom : x1=220, x2=300, y=80
>
>
> --
> LB
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi Auré,
 
Taking this example (FPS is computed at the end of the loop each 100
frames):
(this is the same example as you but not using FileUtils10)
 
################################################
import sys
import pylab as p
import numpy as npy
import time
 
ax2 = p.subplot(212)
ax = p.subplot(211)
canvas = ax.figure.canvas
 
 
# create the initial line
x = npy.arange(0,2*npy.pi,0.01)
line, = p.plot(x, npy.sin(x), animated=True, lw=2)
 
def run(*args):
 background = canvas.copy_from_bbox(ax.bbox)
 # for profiling
 tstart = time.time()
 
 while 1:
 # restore the clean slate background
 canvas.restore_region(background)
 # update the data
 line.set_ydata(npy.sin(x+run.cnt/10.0))
 # just draw the animated artist
 ax.draw_artist(line)
 # just redraw the axes rectangle
 canvas.blit(ax.bbox)
 
 if run.cnt==100:
 # print the timing info and quit
 print 'FPS:' , 100/(time.time()-tstart)
 return
 
 run.cnt += 1
run.cnt = 0
 
 
p.subplots_adjust(left=0.3, bottom=0.3) # check for flipy bugs
p.grid() # to ensure proper background restore
manager = p.get_current_fig_manager()
manager.window.after(100, run)
 
p.show()
################################################
 
This example will work on my machine @99FPS.
Now replace:
ax2 = p.subplot(212)
ax = p.subplot(211)
 
with:
ax = p.subplot(212)
ax2 = p.subplot(211)
 
The image is buggy because the blitting is no more working, still I get
86FPS. So let say no change.
 
Now replace “ax.bbox” with ”ax.get_figure().bbox”:
The bug disappear and I get a small 20 FPS…
 
Tested under windows vista , matplotlib 0.99.1, python 2.5.4.
 
Laurent
Ps: I think ax.getFigure().bbox is getting the whole picture so this is why
it is slower.
 
 
De : Auré Gourrier [mailto:aur...@ya...] 
Envoyé : jeudi 15 octobre 2009 10:32
À : mat...@li...
Objet : Re: [Matplotlib-users] [Solved] Little issue with blitting technique
 
>On Tue, Oct 13, 2009 at 5:06 PM, Laurent Dufr?chou
><lau...@gm...> wrote:
>> Hey, coparing on how GTK2 example is done I've seen a difference between
the two!
>>
>> In QT4Agg example and WX example the code use:
>>
>> canvas.copy_from_bbox(ax.bbox)
>> replacing all occurrence of ax.bbox with ax.get_figure().bbox solved all
the issue I add.
>>
>
>I'm not sure why using ax.bbox does not work, and it SHOULD work.
>Note that animation_blit_gtk.py DOES use ax.bbox.
>
>> Perhaps we should correct the examples.
>> I can send you the good working example if you want.
>
>If using ax.bbox does not work, than it is a bug (either mpl or the
example).
>Unfortunately, this seems to happen only on windows.
>So, please file a bug report (again).
>
>Regards,
>
>-JJ
>
Hy guys,
Just saw your posts. I don't understand the business with the
ax.get_figure().bbox.
I'm also using windows, and a modified version of the animation_blit_tk.py
using imshow work fine for me.
I just checked whether the get_figure() changes anything and I get exactly
the same result in terms of performance.
I attach the code below if it can be of any use.
Cheers,
Auré
# For detailed comments on animation and the techniqes used here, see
# the wiki entry http://www.scipy.org/Cookbook/Matplotlib/Animations
import matplotlib
matplotlib.use('TkAgg')
import sys
import pylab as p
import matplotlib.numerix as nx
import time
from FileUtils10 import fileHandling
# for profiling
tstart = time.time()
tprevious = time.time()
fnamelist = ['....']
ax = p.subplot(111)
canvas = ax.figure.canvas
print 't1 ',time.time()-tprevious
tprevious = time.time()
# create the initial line
dataarr = fileHandling(fnamelist[0]).read()
#print dataarr.dtype
#dataarr = dataarr.astype('uint8')
print 't2 ',time.time()-tprevious
tprevious = time.time()
image = p.imshow(dataarr, animated=True)
print 't3 ',time.time()-tprevious
tprevious = time.time()
def run(*args):
 tprevious = time.time()
 background = canvas.copy_from_bbox(ax.bbox)
 print 't4 ',time.time()-tprevious
 tprevious = time.time()
 while 1:
 #print fnamelist[run.cnt]
 # restore the clean slate background
 canvas.restore_region(background)
 print 't5 ',time.time()-tprevious
 tprevious = time.time()
 # update the data
 dataarr = fileHandling(fnamelist[run.cnt]).readMCCD()
 dataarr *= run.cnt
 print 't6 ',time.time()-tprevious
 tprevious = time.time()
 image.set_data(dataarr)
 print 't7 ',time.time()-tprevious
 tprevious = time.time()
 # just draw the animated artist
 ax.draw_artist(image)
 print 't8 ',time.time()-tprevious
 tprevious = time.time()
 # just redraw the axes rectangle
 canvas.blit(ax.bbox)
 print 't9 ',time.time()-tprevious
 tprevious = time.time()
 if fnamelist[run.cnt] == fnamelist[-1]:
 # print the timing info and quit
 print 'total time:' , time.time()-tstart
 print 'FPS:' , 1000./(time.time()-tstart)
 p.close('all')
 sys.exit()
 run.cnt += 1
run.cnt = 0
 
p.subplots_adjust(left=0.3, bottom=0.3) # check for flipy bugs
p.grid() # to ensure proper background restore
manager = p.get_current_fig_manager()
manager.window.after(100, run)
p.show()
 

Hi,
I'd like to have all sub-fonts (labels, tick labels, text) sans-serif
for a series of plots per default. However the appropriate settings
in .matplotlibrc apparently don't work and this also does not work:
import matplotlib as mpl
mpl.rcParams['text.usetex'] = True
mpl.rcParams['font.family'] = 'sans-serif'
mpl.rcParams['font.sans-serif'] = 'Bitstream Vera Sans'
Any ideas?
TIA
Christian

Thank you, Scott and Matthias!
I was working with matplotlib-version 0.98xxx.I updated 
it, and now the zero arrow is drawn correctly.
Thank you for your help!
Kind regards,
Marie-Therese

 Hi,
I'm using the twiny fonction to plot two functions on the same axes.
I would like to have both informations displayed on the navigation bar.
Now, I have :
 pan/zoom : x=220, y=80
Is-it possible to customize the toolbar in order to have
 pan/zoom : x1=220, x2=300, y=80
-- 
LB

>On Tue, Oct 13, 2009 at 5:06 PM, Laurent Dufr?chou
><lau...@gm...> wrote:
>> Hey, coparing on how GTK2 example is done I've seen a difference between the two!
>>
>> In QT4Agg example and WX example the code use:
>>
>> canvas.copy_from_bbox(ax.bbox)
>> replacing all occurrence of ax.bbox with ax.get_figure().bbox solved all the issue I add.
>>
>
>I'm not sure why using ax.bbox does not work, and it SHOULD work.
>Note that animation_blit_gtk.py DOES use ax.bbox.
>
>> Perhaps we should correct the examples.
>> I can send you the good working example if you want.
>
>If using ax.bbox does not work, than it is a bug (either mpl or the example).
>Unfortunately, this seems to happen only on windows.
>So, please file a bug report (again).
>
>Regards,
>
>-JJ
>
Hy guys,
Just saw your posts. I don't understand the business with the ax.get_figure().bbox.
I'm also using windows, and a modified version of the animation_blit_tk.py using imshow work fine for me.
I just checked whether the get_figure() changes anything and I get exactly the same result in terms of performance.
I attach the code below if it can be of any use.
Cheers,
Auré
# For detailed comments on animation and the techniqes used here, see
# the wiki entry http://www.scipy.org/Cookbook/Matplotlib/Animations
import matplotlib
matplotlib.use('TkAgg')
import sys
import pylab as p
import matplotlib.numerix as nx
import time
from FileUtils10 import fileHandling
# for profiling
tstart = time.time()
tprevious = time.time()
fnamelist = ['....']
ax = p.subplot(111)
canvas = ax.figure.canvas
print 't1 ',time.time()-tprevious
tprevious = time.time()
# create the initial line
dataarr = fileHandling(fnamelist[0]).read()
#print dataarr.dtype
#dataarr = dataarr.astype('uint8')
print 't2 ',time.time()-tprevious
tprevious = time.time()
image = p.imshow(dataarr, animated=True)
print 't3 ',time.time()-tprevious
tprevious = time.time()
def run(*args):
 tprevious = time.time()
 background = canvas.copy_from_bbox(ax.bbox)
 print 't4 ',time.time()-tprevious
 tprevious = time.time()
 while 1:
 #print fnamelist[run.cnt]
 # restore the clean slate background
 canvas.restore_region(background)
 print 't5 ',time.time()-tprevious
 tprevious = time.time()
 # update the data
 dataarr = fileHandling(fnamelist[run.cnt]).readMCCD()
 dataarr *= run.cnt
 print 't6 ',time.time()-tprevious
 tprevious = time.time()
 image.set_data(dataarr)
 print 't7 ',time.time()-tprevious
 tprevious = time.time()
 # just draw the animated artist
 ax.draw_artist(image)
 print 't8 ',time.time()-tprevious
 tprevious = time.time()
 # just redraw the axes rectangle
 canvas.blit(ax.bbox)
 print 't9 ',time.time()-tprevious
 tprevious = time.time()
 if fnamelist[run.cnt] == fnamelist[-1]:
 # print the timing info and quit
 print 'total time:' , time.time()-tstart
 print 'FPS:' , 1000./(time.time()-tstart)
 p.close('all')
 sys.exit()
 run.cnt += 1
run.cnt = 0
 
p.subplots_adjust(left=0.3, bottom=0.3) # check for flipy bugs
p.grid() # to ensure proper background restore
manager = p.get_current_fig_manager()
manager.window.after(100, run)
p.show()
 

>2009年10月15日 Marie-Therese Horstmann <mho...@un...>:
> I currently experience some problem with arrows in polar
> plots.
>
> ---------------------------------------------------------------------------
> Source code to reproduce the zero direction "arrow"
>
> import matplotlib
> import numpy as np
> from matplotlib.pyplot import figure, show, rc, grid
>
> # radar green, solid grid lines
> rc('grid', color='#316931', linewidth=1, linestyle='-')
> rc('xtick', labelsize=15)
> rc('ytick', labelsize=15)
>
> # force square figure and square axes looks better for
> polar, IMO
> width, height = matplotlib.rcParams['figure.figsize']
> size = min(width, height)
> # make a square figure
> fig = figure(figsize=(size, size))
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True,
> axisbg='#d5de9c')
>
> r = np.arange(0, 3.0, 0.01)
> theta = 2*np.pi*r
> ax.plot(theta, r, color='#ee8d18', lw=3)
> ax.set_rmax(2.0)
> grid(True)
>
> ax.set_title("And there was much rejoicing!", fontsize=20)
> #This is the line I added:
> arr = plt.arrow(0, 0.5, 0,1 , alpha = 0.5, width = 0.1,
> edgecolor = 'black', facecolor = 'green',lw = 2)
arr = ax.arrow(0, 0.5, 0, 1, alpha = 0.5, width = 0.1 ...
>
> show()
This works fine for me with matplotlib version 0.99.0 (see attached).
What version are you using?
import matplotlib
print matplotlib.__version__
Cheers,
Scott

>2009年10月15日 Marie-Therese Horstmann <mho...@un...>:
> I currently experience some problem with arrows in polar
> plots.
>
> ---------------------------------------------------------------------------
> Source code to reproduce the zero direction "arrow"
>
> import matplotlib
> import numpy as np
> from matplotlib.pyplot import figure, show, rc, grid
>
> # radar green, solid grid lines
> rc('grid', color='#316931', linewidth=1, linestyle='-')
> rc('xtick', labelsize=15)
> rc('ytick', labelsize=15)
>
> # force square figure and square axes looks better for
> polar, IMO
> width, height = matplotlib.rcParams['figure.figsize']
> size = min(width, height)
> # make a square figure
> fig = figure(figsize=(size, size))
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True,
> axisbg='#d5de9c')
>
> r = np.arange(0, 3.0, 0.01)
> theta = 2*np.pi*r
> ax.plot(theta, r, color='#ee8d18', lw=3)
> ax.set_rmax(2.0)
> grid(True)
>
> ax.set_title("And there was much rejoicing!", fontsize=20)
> #This is the line I added:
> arr = plt.arrow(0, 0.5, 0,1 , alpha = 0.5, width = 0.1,
> edgecolor = 'black', facecolor = 'green',lw = 2)
arr = ax.arrow(0, 0.5, 0, 1, alpha = 0.5, width = 0.1 ...
>
> show()
This works fine for me with matplotlib version 0.99.0 (see attached).
What version are you using?
import matplotlib
print matplotlib.__version__
Cheers,
Scott

Hello everybody,
I currently experience some problem with arrows in polar
plots.
Everything is fine, as long as the arrow does not cross
the zero line. Here is an example from the matplotlib
gallery
(http://matplotlib.sourceforge.net/examples/pylab_examples/polar_demo.html),
but with an arrow pointing at 45° outward.
To create the arrow I just added the following line:
arr = plt.arrow(45, 0.5, 0,1 , alpha = 0.5, width = 0.1,
edgecolor = 'black', facecolor = 'green',lw = 2)
You can find the complete source code at the end of the
mail.
If I want to point the arrow in zero direction,
arr = plt.arrow(0, 0.5, 0,1 , alpha = 0.5, width = 0.1,
edgecolor = 'black', facecolor = 'green',lw = 2)
there is only the silhouette of an arrow visible, but
nearly everthing seems to be green (as the arrow should
be). For me it seems as there are some problems with the
periodicity in polar plots.
Does anyone have an idea or a workaround?
Thank you very much in advance
Marie-Therese
---------------------------------------------------------------------------
Source code to reproduce the zero direction "arrow"
import matplotlib
import numpy as np
from matplotlib.pyplot import figure, show, rc, grid
# radar green, solid grid lines
rc('grid', color='#316931', linewidth=1, linestyle='-')
rc('xtick', labelsize=15)
rc('ytick', labelsize=15)
# force square figure and square axes looks better for
polar, IMO
width, height = matplotlib.rcParams['figure.figsize']
size = min(width, height)
# make a square figure
fig = figure(figsize=(size, size))
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True,
axisbg='#d5de9c')
r = np.arange(0, 3.0, 0.01)
theta = 2*np.pi*r
ax.plot(theta, r, color='#ee8d18', lw=3)
ax.set_rmax(2.0)
grid(True)
ax.set_title("And there was much rejoicing!", fontsize=20)
#This is the line I added:
arr = plt.arrow(0, 0.5, 0,1 , alpha = 0.5, width = 0.1,
edgecolor = 'black', facecolor = 'green',lw = 2)
show()

On Tue, Oct 13, 2009 at 4:53 PM, Laurent Dufréchou
<lau...@gm...> wrote:
> (still your gtk example is more beautiful but 10 times slower than other examples, so is blitting really working in this case ?)
What example do you mean?
The performance will depend on complexity of the plot items that need
to be drawn every time. So, some example may be slower than others.
-JJ

On Tue, Oct 13, 2009 at 5:06 PM, Laurent Dufréchou
<lau...@gm...> wrote:
> Hey, coparing on how GTK2 example is done I've seen a difference between the two!
>
> In QT4Agg example and WX example the code use:
>
> canvas.copy_from_bbox(ax.bbox)
> replacing all occurrence of ax.bbox with ax.get_figure().bbox solved all the issue I add.
>
I'm not sure why using ax.bbox does not work, and it SHOULD work.
Note that animation_blit_gtk.py DOES use ax.bbox.
> Perhaps we should correct the examples.
> I can send you the good working example if you want.
If using ax.bbox does not work, than it is a bug (either mpl or the example).
Unfortunately, this seems to happen only on windows.
So, please file a bug report (again).
Regards,
-JJ
>
> Cheers,
> Laurent
>
>
>> -----Message d'origine-----
>> De : Laurent Dufrechou [mailto:LDu...@ma...]
>> Envoyé : mardi 13 octobre 2009 19:02
>> À : Jae-Joon Lee
>> Cc : mat...@li...
>> Objet : Re: [Matplotlib-users] Little issue with blitting technique
>>
>> Hello,
>>
>> I've tested so far with wx and QT4 backend.
>> The two are buggy.
>> Easy way to reproduce the bug (another way I mean)
>>
>> ax = p.subplot(212)
>> ax2 = p.subplot(211)
>>
>> and the two backends got the same error.
>>
>> Note that I'm under windows. I'll try under linux tonight just to
>> check.
>> I'll also try gtk backend as you suggest.
>>
>> Update in next email :)
>>
>> > -----Message d'origine-----
>> > De : Jae-Joon Lee [mailto:lee...@gm...]
>> > Envoyé : mardi 13 octobre 2009 18:36
>> > À : Laurent Dufrechou
>> > Cc : mat...@li...
>> > Objet : Re: [Matplotlib-users] Little issue with blitting technique
>> >
>> > I haven't tested it with qt4, but with gtk, add_axes DOES work.
>> >
>> > So, can you try other backends and see if they work?
>> >
>> > And, I believe that add_subplot -> add_axes is a only change you
>> made?
>> >
>> > Unless the problem is persistent among other backends, I hope other
>> > developers who use qt4 backend step in and help.
>> >
>> > Regards,
>> >
>> > -JJ
>> >
>> >
>> > On Thu, Oct 8, 2009 at 11:30 AM, Laurent Dufrechou
>> > <LDu...@ma...> wrote:
>> > > Hello,
>> > >
>> > >
>> > >
>> > > I’ve just discovered blitting technique to improve performances.
>> > >
>> > > I’m using this example
>> > >
>> >
>> http://matplotlib.sourceforge.net/examples/animation/animation_blit_qt4
>> > .html
>> > >
>> > >
>> > >
>> > > I encounter an issue if instead of using subplot I use add_axes
>> > method to
>> > > hand define where I want my plot.
>> > >
>> > > In this case blitting is no more working like if restore_region was
>> > not
>> > > restoring context...
>> > >
>> > >
>> > >
>> > > def __init__(self):
>> > >
>> > >     FigureCanvas.__init__(self, Figure())
>> > >
>> > >
>> > >
>> > >     #self.ax = self.figure.add_subplot(111)
>> > >
>> > >     self.ax = self.figure.add_axes([0.1,0.1,0.8,0.2])
>> > >
>> > >
>> > >
>> > > Any idea why in this case the example given is not working?
>> > >
>> > >
>> > >
>> > > Cheers,
>> > >
>> > > Laurent
>> > >
>> > > -------------------------------------------------------------------
>> --
>> > ---------
>> > > Come build with us! The BlackBerry(R) Developer Conference in SF,
>> CA
>> > > is the only developer event you need to attend this year. Jumpstart
>> > your
>> > > developing skills, take BlackBerry mobile applications to market
>> and
>> > stay
>> > > ahead of the curve. Join us from November 9 - 12, 2009. Register
>> now!
>> > > http://p.sf.net/sfu/devconference
>> > > _______________________________________________
>> > > Matplotlib-users mailing list
>> > > Mat...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> > >
>> > >
>> -----------------------------------------------------------------------
>> -------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On Tue, Oct 13, 2009 at 1:02 PM, Laurent Dufrechou
<LDu...@ma...> wrote:
> Hello,
>
> I've tested so far with wx and QT4 backend.
> The two are buggy.
> Easy way to reproduce the bug (another way I mean)
>
> ax = p.subplot(212)
> ax2 = p.subplot(211)
>
On mac with wxgtk, it works fine.
Maybe this is an windows only issue.
> and the two backends got the same error.
Since nobody steped in, and I don't use windows, can you file a bug report.
http://sourceforge.net/tracker/?atid=560720&group_id=80706&func=browse
Please provide a short, complete example that reproduces the bug. Also
the error message you get.
-JJ
>
> Note that I'm under windows. I'll try under linux tonight just to check.
> I'll also try gtk backend as you suggest.
>
> Update in next email :)
>
>> -----Message d'origine-----
>> De : Jae-Joon Lee [mailto:lee...@gm...]
>> Envoyé : mardi 13 octobre 2009 18:36
>> À : Laurent Dufrechou
>> Cc : mat...@li...
>> Objet : Re: [Matplotlib-users] Little issue with blitting technique
>>
>> I haven't tested it with qt4, but with gtk, add_axes DOES work.
>>
>> So, can you try other backends and see if they work?
>>
>> And, I believe that add_subplot -> add_axes is a only change you made?
>>
>> Unless the problem is persistent among other backends, I hope other
>> developers who use qt4 backend step in and help.
>>
>> Regards,
>>
>> -JJ
>>
>>
>> On Thu, Oct 8, 2009 at 11:30 AM, Laurent Dufrechou
>> <LDu...@ma...> wrote:
>> > Hello,
>> >
>> >
>> >
>> > I’ve just discovered blitting technique to improve performances.
>> >
>> > I’m using this example
>> >
>> http://matplotlib.sourceforge.net/examples/animation/animation_blit_qt4
>> .html
>> >
>> >
>> >
>> > I encounter an issue if instead of using subplot I use add_axes
>> method to
>> > hand define where I want my plot.
>> >
>> > In this case blitting is no more working like if restore_region was
>> not
>> > restoring context...
>> >
>> >
>> >
>> > def __init__(self):
>> >
>> >     FigureCanvas.__init__(self, Figure())
>> >
>> >
>> >
>> >     #self.ax = self.figure.add_subplot(111)
>> >
>> >     self.ax = self.figure.add_axes([0.1,0.1,0.8,0.2])
>> >
>> >
>> >
>> > Any idea why in this case the example given is not working?
>> >
>> >
>> >
>> > Cheers,
>> >
>> > Laurent
>> >
>> > ---------------------------------------------------------------------
>> ---------
>> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> > is the only developer event you need to attend this year. Jumpstart
>> your
>> > developing skills, take BlackBerry mobile applications to market and
>> stay
>> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> > http://p.sf.net/sfu/devconference
>> > _______________________________________________
>> > Matplotlib-users mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> >
>> >
>

Jouni K. Seppänen wrote:
> David Cournapeau <da...@ar...> writes:
> 
>
> The setup.cfg file is included in the distribution by mistake. Just
> delete it before building.
> 
Ah, that would explain it, indeed. Thanks,
David