SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S



1
(6)
2
(5)
3
4
5
6
(4)
7
(3)
8
9
(5)
10
11
12
(1)
13
14
15
(4)
16
(1)
17
(4)
18
(1)
19
(4)
20
(4)
21
(5)
22
(1)
23
(3)
24
(6)
25
(1)
26
(19)
27
(13)
28
(9)




Showing 4 results of 4

From: Tom D. <tom...@al...> - 2006年02月19日 21:48:22
 I am generating a few hundred graphs and doing so takes on the order of
about 10-15 minutes. Which seems to me rather slow. When I profile my cod=
e
it identifies the calls to get_yticklabels and get_xticklabels as taking
over 90% of the time. This seems strange but my calls to these functions
are merely a sort round about way of setting the font size of the axis tick
labels and suppressing the text for the xticklabels. Is there a more
efficient and cleaner way to do this?
 artist.setp(axes.get_yticklabels(), visible=3DTrue, fontsize=3D7)
 artist.setp(axes.get_xticklabels(), visible=3DFalse)
I am using matplotlib version 0.83.1 and the .png format for my output, if
that helps. Though the profiler seems to suggest that the output is
blazingly fast and it is only these calls to the get_?ticklabels that are
slow.
From: David T. <dav...@gm...> - 2006年02月19日 11:33:09
Note:
 The "crash" only occurs if you run the script and press directly the
replot button.
If you click on the second page of the notebook then back to the first and
"replot"
no problem. Though no problem at all if the "# GTK+ 2.x style draw()" is
used in
matplotlib_gtk.py
Regards,
David
2006年2月19日, David TREMOUILLES <dav...@gm...>:
>
> Here is a quick and dirty minimal code reproducing the problem.
>
> David
>
> 2006年2月17日, Steve Chaplin <ste...@ya...>:
> >
> > On Wed, 2006年02月15日 at 20:36 -0800,
> > mat...@li... wrote:
> > > Hello,
> > >
> > > I'm using matplotlib figures in several places at a time in my GT=
K
> >
> > > based app (means different page in a notebook).
> > > I have trace a bug I partially solved but still doubting if it is a
> > > matplotlib bug or a bad design of my app.
> > >
> > > Matplotlib 0.86.2
> > > pygtk-2.8.4
> > > gtk+-2.8.6
> > >
> > > Here is the problem:
> > >
> > > in matplotlib/backends/backend_gtk.py file, in
> > > class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> > > ... in:
> > >
> > > def draw(self):
> > > # synchronous window redraw (like GTK+ 1.2 used to do)
> > > # Note: this does not follow the usual way that GTK redraws,
> > > # which is asynchronous redraw using calls to
> > > gtk_widget_queue_draw(),
> > > # which triggers an expose-event
> > >
> > > # GTK+ 2.x style draw()
> > > 1- self._need_redraw =3D True
> > > 1- self.queue_draw()
> > >
> > > # synchronous draw (needed for animation)
> > > 2- x, y, w, h =3D self.allocation
> > > 2- if w<3 or h<3: return # empty fig
> > >
> > > 2- self._pixmap_prepare (w, h)
> > > 2- self._render_figure(self._pixmap, w, h)
> > > 2- self._need_redraw =3D False
> > > 2- self.window.draw_drawable (self.style.fg_gc[self.state],
> > > 2- self._pixmap, 0, 0, 0, 0, w, h)
> > >
> > >
> > > If I use method 1- (and comment 2-) no problem, all run smoothly...
> > > But using the default method, switching on method 2- (and comment 1-)
> > > I get the followig error message when trying to redraw one of the
> > > figure
> > > (the figure is plotted correctly the first time. No change made to th=
e
> > > figure, just redrawing...)
> > >
> > > ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> > > GtkWarning: gdk_pixmap_new: assertion `(drawable !=3D NULL) || (depth=
 !=3D
> >
> > > -1)' failed
> > > self._pixmap_height)
> > > Traceback (most recent call last):
> > > ...
> > > self.canvas_leak.draw()
> > > File
> > > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", lin=
e
> >
> > > 250, in draw
> > > self._pixmap_prepare (w, h)
> > > File
> > > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", lin=
e
> > > 298, in _pixmap_prepare
> > > self._pixmap_height)
> > > RuntimeError: could not create GdkPixmap object
> > >
> > > Somebody has a clue ???
> > >
> > Its difficult to say if its bug in backend_gtk.py, it depends on exactl=
y
> > what your application is doing. You would need to post a minimal test
> > case that demonstrates the bug so we could see whats going on.
> >
> > Steve
> >
> > Send instant messages to your online friends
> > http://au.messenger.yahoo.com
> >
> >
>
>
From: David T. <dav...@gm...> - 2006年02月19日 10:04:21
Attachments: test_mpl_bug.py
Here is a quick and dirty minimal code reproducing the problem.
David
2006年2月17日, Steve Chaplin <ste...@ya...>:
>
> On Wed, 2006年02月15日 at 20:36 -0800,
> mat...@li... wrote:
> > Hello,
> >
> > I'm using matplotlib figures in several places at a time in my GTK
> > based app (means different page in a notebook).
> > I have trace a bug I partially solved but still doubting if it is a
> > matplotlib bug or a bad design of my app.
> >
> > Matplotlib 0.86.2
> > pygtk-2.8.4
> > gtk+-2.8.6
> >
> > Here is the problem:
> >
> > in matplotlib/backends/backend_gtk.py file, in
> > class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> > ... in:
> >
> > def draw(self):
> > # synchronous window redraw (like GTK+ 1.2 used to do)
> > # Note: this does not follow the usual way that GTK redraws,
> > # which is asynchronous redraw using calls to
> > gtk_widget_queue_draw(),
> > # which triggers an expose-event
> >
> > # GTK+ 2.x style draw()
> > 1- self._need_redraw = True
> > 1- self.queue_draw()
> >
> > # synchronous draw (needed for animation)
> > 2- x, y, w, h = self.allocation
> > 2- if w<3 or h<3: return # empty fig
> >
> > 2- self._pixmap_prepare (w, h)
> > 2- self._render_figure(self._pixmap, w, h)
> > 2- self._need_redraw = False
> > 2- self.window.draw_drawable (self.style.fg_gc[self.state],
> > 2- self._pixmap, 0, 0, 0, 0, w, h)
> >
> >
> > If I use method 1- (and comment 2-) no problem, all run smoothly...
> > But using the default method, switching on method 2- (and comment 1-)
> > I get the followig error message when trying to redraw one of the
> > figure
> > (the figure is plotted correctly the first time. No change made to the
> > figure, just redrawing...)
> >
> > ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> > GtkWarning: gdk_pixmap_new: assertion `(drawable != NULL) || (depth !=
> > -1)' failed
> > self._pixmap_height)
> > Traceback (most recent call last):
> > ...
> > self.canvas_leak.draw()
> > File
> > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> > 250, in draw
> > self._pixmap_prepare (w, h)
> > File
> > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> > 298, in _pixmap_prepare
> > self._pixmap_height)
> > RuntimeError: could not create GdkPixmap object
> >
> > Somebody has a clue ???
> >
> Its difficult to say if its bug in backend_gtk.py, it depends on exactly
> what your application is doing. You would need to post a minimal test
> case that demonstrates the bug so we could see whats going on.
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
From: Andrew S. <str...@as...> - 2006年02月19日 03:18:13
Hi,
I've got a situation where I'd like to create several instances of Axes
but not set their position until later. It seems I have to jump through
hoops to actually create a new axes, contrary to my expectation:
$ ipython -pylab
In [1]: a=axes()
In [2]: a
Out[2]: <matplotlib.axes.Subplot instance at 0x2aaab158a758>
In [3]: b=axes()
In [4]: b
Out[4]: <matplotlib.axes.Subplot instance at 0x2aaab158a758>
I can see what's happening here:
 1. pylab.axes() calls subplot(111) when no arguments are given.
 2. subplot(111) uses some smarts to figure out if an Axes instance for
subplot(111) has already been given and, if so, returns a reference to that.
Both points 1 and 2 seem reasonable on their own, but when combined, as
in my example, the outcome is not intuitive. Is this behavior desired?
Does anyone depend on it?
It goes deeper -- even Figure.add_axes() returns an old Axes instance if
the rect given has been seen before. I'd argue that people delving into
the OO innards of matplotlib should be able to handle keeping a
reference to instances of Axes they've created. Can we change this
behavior or would it cause massive breakage somewhere?
Cheers!
Andrew

Showing 4 results of 4

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /