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
(1) |
2
(1) |
3
(3) |
4
(2) |
5
|
6
|
7
(8) |
8
|
9
|
10
(3) |
11
(2) |
12
(2) |
13
(2) |
14
(6) |
15
(1) |
16
|
17
|
18
(8) |
19
(1) |
20
(9) |
21
|
22
(6) |
23
(1) |
24
(13) |
25
(8) |
26
(5) |
27
(3) |
28
(7) |
29
(4) |
30
|
|
|
|
From: Eric F. <ef...@ha...> - 2008-04-20 21:13:57
|
Stéfan van der Walt wrote: > On 20/04/2008, Eric Firing <ef...@ha...> wrote: >>> Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk >>> >> Very odd. Would you try writing out postscript and pdf, please, and see >> whether they behave the same way? > > The contour lines are still visible: > > http://mentat.za.net/refer/contours.ps I don't see any contour lines; I see only the boundaries between patches. In other words, the plot looks the way I would expect it to. This is with evince or gv on a linux machine. (Both fail when trying to blow up the plot to 400%, but work at 200%.) My sense is that there is an optical illusion effect making the boundaries look somewhat line-like, but it doesn't sound like this is what you are talking about, so I am baffled. Do you see the problem if you run contourf_demo.py and use the gui to generate png, pdf, and ps files from figure 1? I still can't see any sign of it anywhere. Would you send a png file generated with and without your workaround, please? That should get around any differences in postscript interpreters. Also helpful would be a ps file with and without your workaround, preferably of an extremely simple example so it will be easy to see the difference in the generated ps. It sounds like you are seeing something fairly subtle that I am having a hard time seeing, and that is new with the transforms branch. Your patch must be pointing in the right direction, but I don't understand why, yet, and there should be no need for a kwarg; we don't want boundaries with contourf, period. The reason is that the contour algorithm we are using makes patches with slits, so rendering the boundary does not have the desired effect; one needs to call contour separately to get valid lines as boundaries. Then there is the problem that those lines don't *always* coincide with the corresponding patch boundaries, but this is generally not a problem unless the contours are ill-determined anyway. It is still bad, but there is no easy solution. Eric |
From: S. v. d. W. <st...@su...> - 2008-04-20 19:57:46
|
On 20/04/2008, Eric Firing <ef...@ha...> wrote: > > Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk > > > Very odd. Would you try writing out postscript and pdf, please, and see > whether they behave the same way? The contour lines are still visible: http://mentat.za.net/refer/contours.ps > > 2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX > > currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2). > > I saw John posted a compiler error (resulting from this problem) on > > some other list, so it's something to keep in mind. > > > Yes, my colleague, Jules, and I ran into this yesterday. Very frustrating. > We also ran into some sort of problem involving, apparently, a mixture of > libraries and/or object modules with and without dual ppc/intel code, but > from the error messages it was impossible for us to track down beyond that. > It might have been obvious to an OSX wizard. Jules was trying to follow > John's instructions carefully. Numpy went in flawlessly. Scipy went in OK, > we think, but the test needed nosetest, and then when that was installed, it > failed. We gave up on the matplotlib installation. I did the following: a) Use macports to install gcc 4.2 b) Create /tmp/bin and link into it gcc-mp-4.2 and g++-mp-4.2. Set this as my $PATH (otherwise, the system gcc is still picked up sometimes, for some reason) Now, matplotlib should build, but I still see many errors of the form python(37779) malloc: *** error for object 0xa010c6d8: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug whenever I generate a plot. Seems to work OK though. Cheers Stéfan |
From: John H. <jd...@gm...> - 2008-04-20 15:16:46
|
On Mon, Apr 7, 2008 at 8:38 AM, Manuel Metz <mm...@as...> wrote: > The problem is that "release_zoom" in backend_bases.py is called twice in > the above case if zoomed to a twinx'ed plot. One way to fix this behavior is > to set a "twin" attribute to the axes instance. Attached is a patch against > the 0.91 trunk. > > John: is this okay or is there a better way to fix the problem? Hey Manuel, thanks for fixng this. I don't think it is critical that this be fixed on the maintenance branch since it is a relatively small bug (only applies in twinned axes) but I have a minor suggestion for you in the fix for the trunk. It is not a good idea for a class outside the axes to access a "protected" "_twinx" attribute. Probably better is to either make the attribute public by naming it "istwinx" or something like that, or make a method. JDH |
From: Manuel M. <mm...@as...> - 2008-04-20 10:55:07
|
Hi, I have fixed the double-zoom Bug in the trunk (revision 5053), but not in the 0_91maint branch. In 0.91 it's not so easy to find out whether an axes is shared with another (cbook:Group is nice ;-) ) For 0.91: is it always guaranteed that the release_zoom event for the master is called before that of the shared axes ? (I don't think so.) Then it would be more easy to test for the shared axes ... So there is still the old solution (see previous post) to introduce an argument twinx,twiny #%$(/"/'+*#*# I don't like that. Manuel |
From: Eric F. <ef...@ha...> - 2008-04-20 01:01:34
|
Stephane Raynaud wrote: > Hi, > > I think that "collection._alpha = self.alpha" (or something better) > are missing in ContoutSet.__init__, because _alpha from collections > (Line or Poly) overrides the alpha value the color of > "collection.set_color(color)" found in method "changed" of ContourSet. > Therefore, alpha doesn't work for contours (filled or not). > > Nota: If "collection.set_alpha" is used, it fails with line contouring > because self._edgecolors is an empty list. > > I hope it can help. > Stephane, It did help, thank you. I have fixed this in svn, rev 5051. Eric |
From: Eric F. <ef...@ha...> - 2008-04-20 00:13:36
|
Stéfan van der Walt wrote: > Hi Eric > > On 18/04/2008, Eric Firing <ef...@ha...> wrote: >> It doesn't on my machine with backend GtkAgg, and I have never seen this >> behavior. What backend are you using? > > Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk Very odd. Would you try writing out postscript and pdf, please, and see whether they behave the same way? > 2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX > currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2). > I saw John posted a compiler error (resulting from this problem) on > some other list, so it's something to keep in mind. Yes, my colleague, Jules, and I ran into this yesterday. Very frustrating. We also ran into some sort of problem involving, apparently, a mixture of libraries and/or object modules with and without dual ppc/intel code, but from the error messages it was impossible for us to track down beyond that. It might have been obvious to an OSX wizard. Jules was trying to follow John's instructions carefully. Numpy went in flawlessly. Scipy went in OK, we think, but the test needed nosetest, and then when that was installed, it failed. We gave up on the matplotlib installation. Eric > > Regards > Stéfan |
From: S. v. d. W. <st...@su...> - 2008-04-19 18:20:58
|
Hi Eric On 18/04/2008, Eric Firing <ef...@ha...> wrote: > It doesn't on my machine with backend GtkAgg, and I have never seen this > behavior. What backend are you using? Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk 2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2). I saw John posted a compiler error (resulting from this problem) on some other list, so it's something to keep in mind. Regards Stéfan |
From: Fernando P. <fpe...@gm...> - 2008-04-18 20:56:49
|
On Fri, Apr 18, 2008 at 1:13 PM, Eric Firing <ef...@ha...> wrote: > Fernando, > > I think I have fixed that problem and committed it to svn. I expect there > is still more to be done to make the handling of colors and 'none' more > consistent throughout mpl, but this is a start. Thanks a lot, Eric! It looks OK here, I'll report if I find anything else out of place. Regards, f |
From: Eric F. <ef...@ha...> - 2008-04-18 20:13:33
|
Fernando Perez wrote: > On Thu, Apr 17, 2008 at 7:15 PM, Eric Firing <ef...@ha...> wrote: >> Fernando, >> >> Thanks for the bug report. I see what the problem is. Unless someone else >> wants to do it (in which case please do so, but tell me you will), I can fix >> it within a few days at the most, and possibly later today. > > Thanks for the prompt response, Eric. For now I can fortunately use > faceted, but I'll keep an eye out on the list for updates to test. > > Regards, > > f Fernando, I think I have fixed that problem and committed it to svn. I expect there is still more to be done to make the handling of colors and 'none' more consistent throughout mpl, but this is a start. Eric |
From: Eric F. <ef...@ha...> - 2008-04-18 16:31:41
|
Stéfan van der Walt wrote: > Hi all, > > I noticed that, contrary to what the docstring says, > > contourf(Z,10) > > draws contour lines on the different levels. Stefan, It doesn't on my machine with backend GtkAgg, and I have never seen this behavior. What backend are you using? Eric > > The attached patch adds a draw_contours keyword that explicitly > controls this behaviour. I don't know why it works (I set linewidths > to 1 and the lines disappear?!), but it gives some idea of what I > needed. > > Could someone update the docstring, or fix the broken behaviour? > > Thanks > Stéfan > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: S. v. d. W. <st...@su...> - 2008-04-18 12:33:37
|
Hi all, I noticed that, contrary to what the docstring says, contourf(Z,10) draws contour lines on the different levels. The attached patch adds a draw_contours keyword that explicitly controls this behaviour. I don't know why it works (I set linewidths to 1 and the lines disappear?!), but it gives some idea of what I needed. Could someone update the docstring, or fix the broken behaviour? Thanks Stéfan |
From: Christopher E. <cje...@uc...> - 2008-04-18 02:40:54
|
Fernando Perez wrote the following on 04/17/2008 06:31 PM: > ps - for now, using the deprecated 'faceted=False' seems to still > work, so I'll go with that. I noticed this a few days ago as well...using edgecolors='None' seemed to have the same effect as faceted=False. This brings up a couple issues. 1) I find the shading=* in the docstring to be a bit confusing. The equal sign makes me think of keyword arguments. Since 'shading' is not a valid keyword, additional clarity might result if we do not use the equal sign. 2) If we remove the equal signs, we might have something like this: This kwarg is deprecated; please use the edgecolors kwarg instead: flat shading --> edgecolors='None' faceted shading --> edgecolors=None But even this is confusing. Reading http://www.physnet.uni-hamburg.de/physnet/matlab/help/techdoc/ref/shading.html makes me think we should have: This kwarg is deprecated; please use the edgecolors kwarg instead: flat shading --> edgecolors=None For faceted shading, edgecolors can be any mpl color or sequence of colors. --- So it seems like the code is working, but that the docstring is wrong. Perhaps the behavior should be changed so that edgecolors must be set to None rather than 'None' when requesting flat shading. ~C |
From: Fernando P. <fpe...@gm...> - 2008-04-18 02:26:40
|
On Thu, Apr 17, 2008 at 7:15 PM, Eric Firing <ef...@ha...> wrote: > Fernando, > > Thanks for the bug report. I see what the problem is. Unless someone else > wants to do it (in which case please do so, but tell me you will), I can fix > it within a few days at the most, and possibly later today. Thanks for the prompt response, Eric. For now I can fortunately use faceted, but I'll keep an eye out on the list for updates to test. Regards, f |
From: Eric F. <ef...@ha...> - 2008-04-18 02:15:24
|
Fernando, Thanks for the bug report. I see what the problem is. Unless someone else wants to do it (in which case please do so, but tell me you will), I can fix it within a few days at the most, and possibly later today. Eric Fernando Perez wrote: > Hi all, > > the scatter docstring says: > > * faceted: if True, will use the default edgecolor for the > markers. If False, will set the edgecolors to be the same > as the facecolors. > This kwarg is deprecated; > please use the edgecolors kwarg instead: > shading='flat' --> edgecolors='None' > shading='faceted --> edgecolors=None > > However (running MPL from SVN here): > > In [90]: scatter(range(10),range(10),edgecolors=None) > > ends with > > /home/fperez/usr/opt/lib64/python2.5/site-packages/matplotlib/collections.pyc > in set_edgecolor(self, c) > 303 self._edgecolors = npy.array([]) > 304 else: > --> 305 self._edgecolors = _colors.colorConverter.to_rgba_array(c) > 306 set_edgecolors = set_edgecolor > 307 > > /home/fperez/usr/opt/lib64/python2.5/site-packages/matplotlib/colors.pyc > in to_rgba_array(self, c, alpha) > 323 # it. This is needed for examples/dynamic_collections.py. > 324 if not isinstance(c, (list, npy.ndarray)): # > specific; don't need duck-typing > --> 325 c = list(c) > 326 for i, cc in enumerate(c): > 327 c[i] = self.to_rgba(cc, alpha) # change in place > > TypeError: 'NoneType' object is not iterable > > > Am I doing something wrong? > > Thanks, > > f > > ps - for now, using the deprecated 'faceted=False' seems to still > work, so I'll go with that. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Fernando P. <fpe...@gm...> - 2008-04-18 01:31:26
|
Hi all, the scatter docstring says: * faceted: if True, will use the default edgecolor for the markers. If False, will set the edgecolors to be the same as the facecolors. This kwarg is deprecated; please use the edgecolors kwarg instead: shading='flat' --> edgecolors='None' shading='faceted --> edgecolors=None However (running MPL from SVN here): In [90]: scatter(range(10),range(10),edgecolors=None) ends with /home/fperez/usr/opt/lib64/python2.5/site-packages/matplotlib/collections.pyc in set_edgecolor(self, c) 303 self._edgecolors = npy.array([]) 304 else: --> 305 self._edgecolors = _colors.colorConverter.to_rgba_array(c) 306 set_edgecolors = set_edgecolor 307 /home/fperez/usr/opt/lib64/python2.5/site-packages/matplotlib/colors.pyc in to_rgba_array(self, c, alpha) 323 # it. This is needed for examples/dynamic_collections.py. 324 if not isinstance(c, (list, npy.ndarray)): # specific; don't need duck-typing --> 325 c = list(c) 326 for i, cc in enumerate(c): 327 c[i] = self.to_rgba(cc, alpha) # change in place TypeError: 'NoneType' object is not iterable Am I doing something wrong? Thanks, f ps - for now, using the deprecated 'faceted=False' seems to still work, so I'll go with that. |
From: Christopher B. <Chr...@no...> - 2008-04-15 05:54:56
|
Ted Drain wrote: > Just a note about the speed of blitting: Your points are well taken. I had forgotten about remote X sessions, and yes, if you need to convert to a different type of pixmap, that can take time too, so keeping it to just what's needed does make sense. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Ted D. <ted...@jp...> - 2008-04-14 14:40:53
|
Just a note about the speed of blitting: Generally speaking, blitting on a local machine is VERY fast. However, if you log in to a remote machine and display the window locally (remote machine to local X server), blitting can be the slowest part of the whole operation. Profiling of the QtAgg backend shows the following items as the slowest parts: 1) Convert the QImage (agg RGB) to QPixmap (display depth and resolution) 2) blitting the pixmap to the screen 3) Agg drawing calls Of course the relative speeds here depend a lot on what's being drawn (agg calls), how many pixels there are (converting and blitting), how fast the network is (blitting), how close the screen is to the agg buffer in terms of resolution and depth (RGB conversion) so timings between these components can vary a lot. In short: there are definitely cases where blitting the smallest part of the image that's necessary is a big help. Ted > -----Original Message----- > From: mat...@li... > [mailto:mat...@li...] On Behalf Of > Gregor Thalhammer > Sent: Monday, April 14, 2008 1:03 AM > To: Christopher Barker; mat...@li... > Subject: Re: [matplotlib-devel] Unnecessary rerendering in wx/wxagg > backends > > Hi Christopher, > > thanks for your valueable feedback. I am proceeding slowly, but > steadily. > > > > > backend_qtagg.py seems to contain a proper (more or > >> less, see other postings of Ted Drain) implementation of double > >> buffered drawing that avoids unnecessary rerendering of the bitmap. > > > > It still feels a bit kludgy to me -- a paint event should simply copy > > the bitmap to the screen, any re-rendering should be triggered by > > other events -- either a re-size, or explicitly by > > figure.canvas.draw() or something. Anyway, given the current > > structure, this looks like the way to go. > I agree, this is currently more a workaround for some missing > rererenderings. It seems to me, that rendering the figure is avoided as > much as possible. Possibly this is due to the support for the vector > graphic backends (postscript, pdf, svg)? I guess that with these > backends rendering means actually creating the output file, but I > didn't > have a look at the source code. > >> self._need_rerender = True > > > > Where does this get set to True again? On a Figure.canvas.draw() > call? > Actually nowhere else. In the QtAgg backend, in Figure.canvas.draw this > is set to True, and then a repaint event is triggered, but no explicit > rerendering. I didn't get this fact from the beginning. As stated > above, > this command is essentially a workaround for a missing initial > rerendering after creating the FigureCanvas. > > > >> changed _onPaint(...) to following (note: removed evt.Skip() at > end!) > >> def _onPaint(self, evt): > > > >> #repaint only damaged parts of window > > > > I don't know that this is needed, bitting the whole Window is > > blazingly fast anyway -- but if it works, why not? > Actually, this code repaints the bounding box containing all damaged > regions. I did it because the QtAgg backend also did it like this. If I > quickly move another window in front of a matplotlib figure, than I can > see I small difference. > >> By these change in onPaint a rerendering of the bitmap is done only > if > >> needed (in fact, this is needed only once after the figure is shown > >> for the first time). > > > > Well, it's needed whenever the figure changes -- on each > > figure.canvas.draw() call, I guess. > You are right. To express it more clearly: In my changed code a > rererendering of the bitmap is done on each figure.canvas.draw() (as > before). In the onPaint event callback no rerendering is done except > the > very first it's get callad after the figure has been created (changed > behaviour). > > > > > I moved code from gui_repaint() into > >> _onPaint. Calls to gui_repaint() in other methods (e.g., draw) might > >> now be > >> replaced by > >> > >> self.Refresh() > >> self.Update() #this is optional, leeds to an immediate repaint > > > > Maybe -- I've found (at least on OS-X) that using a ClientDC is still > > required sometimes to get instant response. This is key if you're > > doing anything like animation. > Initially I thought this is optional and might avoid some unnecessary > repainting. Later I discovered that it is crucial for interactive > panning. And for animation. > > > >> def draw(self, repaint=True): > >> """ > >> Render the figure using agg. > >> """ > >> DEBUG_MSG("draw()", 1, self) > >> FigureCanvasAgg.draw(self) > >> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), > >> None) > >> if repaint: > >> self.Refresh(eraseBackground = False) > >> self.Update() > > > > I think maybe these should be calls to gui_repaint, which will get > you > > to a ClientDC instead of waiting for a paint event -- Update is not > > always instant. > Didn't know this. The wxWidgets documentation states about Update(): > "Calling this method immediately repaints the invalidated area of the > window..." > > > >> I had to add some calls to figure.canvas.draw in my mpl-embedded-in- > wx > >> application, e.g., after changing a colormap range, to give a > >> immediate change on screen. Before due to the frequent rerendering I > >> didn't notice that these statements were missing. > > > > I agree -- I think I'm going to need to add a few of those too. The > > problem is that this is a change, and other folks' code is going to > > break too. > At least for my case I would say that these changes to the wx backend > didn't break my code, they revealed mistakes in my code (I used > Refresh() instead of figure.canvas.draw() calls to get a rerendering of > the matplotlib figure). > > >> As Chris Barker noticed, Figure.draw() does not lead to a repainting > >> of the window on screen. This seems to be intended. Instead one > should > >> use pylab.draw() or Figure.canvas.draw(). > > > > I think you're right -- I should have looked at the pylab.draw code > to > > see what it did. Though I think Figure should have a method that does > > do an instant update...DrawNow?? > For GUI backends I would even expect that Figure.draw() should update > the figure on screen. However, I don't know how this should be > implemented for not breaking code which uses other backends. > >> What about the politics of supporting older versions of wxWidgets? > > > > I wouldn't bother, but I'm a bleeding-edge kind of guy. It seems that > > we could at least make sure not to break anything by keeping the old > > code around for older versions, and go all 2.8 for new code, with one > > big 'ol version test at the top of the modules. > Did I understand you correctly: This means to drop support for ancient > versions of wx in newly added code? This makes developing much easier. > > Gregor > > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ > javaone > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Gregor T. <gre...@gm...> - 2008-04-14 08:03:09
|
Hi Christopher, thanks for your valueable feedback. I am proceeding slowly, but steadily. > > > backend_qtagg.py seems to contain a proper (more or >> less, see other postings of Ted Drain) implementation of double >> buffered drawing that avoids unnecessary rerendering of the bitmap. > > It still feels a bit kludgy to me -- a paint event should simply copy > the bitmap to the screen, any re-rendering should be triggered by > other events -- either a re-size, or explicitly by > figure.canvas.draw() or something. Anyway, given the current > structure, this looks like the way to go. I agree, this is currently more a workaround for some missing rererenderings. It seems to me, that rendering the figure is avoided as much as possible. Possibly this is due to the support for the vector graphic backends (postscript, pdf, svg)? I guess that with these backends rendering means actually creating the output file, but I didn't have a look at the source code. >> self._need_rerender = True > > Where does this get set to True again? On a Figure.canvas.draw() call? Actually nowhere else. In the QtAgg backend, in Figure.canvas.draw this is set to True, and then a repaint event is triggered, but no explicit rerendering. I didn't get this fact from the beginning. As stated above, this command is essentially a workaround for a missing initial rerendering after creating the FigureCanvas. > >> changed _onPaint(...) to following (note: removed evt.Skip() at end!) >> def _onPaint(self, evt): > >> #repaint only damaged parts of window > > I don't know that this is needed, bitting the whole Window is > blazingly fast anyway -- but if it works, why not? Actually, this code repaints the bounding box containing all damaged regions. I did it because the QtAgg backend also did it like this. If I quickly move another window in front of a matplotlib figure, than I can see I small difference. >> By these change in onPaint a rerendering of the bitmap is done only if >> needed (in fact, this is needed only once after the figure is shown >> for the first time). > > Well, it's needed whenever the figure changes -- on each > figure.canvas.draw() call, I guess. You are right. To express it more clearly: In my changed code a rererendering of the bitmap is done on each figure.canvas.draw() (as before). In the onPaint event callback no rerendering is done except the very first it's get callad after the figure has been created (changed behaviour). > > > I moved code from gui_repaint() into >> _onPaint. Calls to gui_repaint() in other methods (e.g., draw) might >> now be >> replaced by >> >> self.Refresh() >> self.Update() #this is optional, leeds to an immediate repaint > > Maybe -- I've found (at least on OS-X) that using a ClientDC is still > required sometimes to get instant response. This is key if you're > doing anything like animation. Initially I thought this is optional and might avoid some unnecessary repainting. Later I discovered that it is crucial for interactive panning. And for animation. > >> def draw(self, repaint=True): >> """ >> Render the figure using agg. >> """ >> DEBUG_MSG("draw()", 1, self) >> FigureCanvasAgg.draw(self) >> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), >> None) >> if repaint: >> self.Refresh(eraseBackground = False) >> self.Update() > > I think maybe these should be calls to gui_repaint, which will get you > to a ClientDC instead of waiting for a paint event -- Update is not > always instant. Didn't know this. The wxWidgets documentation states about Update(): "Calling this method immediately repaints the invalidated area of the window..." >> I had to add some calls to figure.canvas.draw in my mpl-embedded-in-wx >> application, e.g., after changing a colormap range, to give a >> immediate change on screen. Before due to the frequent rerendering I >> didn't notice that these statements were missing. > > I agree -- I think I'm going to need to add a few of those too. The > problem is that this is a change, and other folks' code is going to > break too. At least for my case I would say that these changes to the wx backend didn't break my code, they revealed mistakes in my code (I used Refresh() instead of figure.canvas.draw() calls to get a rerendering of the matplotlib figure). >> As Chris Barker noticed, Figure.draw() does not lead to a repainting >> of the window on screen. This seems to be intended. Instead one should >> use pylab.draw() or Figure.canvas.draw(). > > I think you're right -- I should have looked at the pylab.draw code to > see what it did. Though I think Figure should have a method that does > do an instant update...DrawNow?? For GUI backends I would even expect that Figure.draw() should update the figure on screen. However, I don't know how this should be implemented for not breaking code which uses other backends. >> What about the politics of supporting older versions of wxWidgets? > > I wouldn't bother, but I'm a bleeding-edge kind of guy. It seems that > we could at least make sure not to break anything by keeping the old > code around for older versions, and go all 2.8 for new code, with one > big 'ol version test at the top of the modules. Did I understand you correctly: This means to drop support for ancient versions of wx in newly added code? This makes developing much easier. Gregor |
From: John H. <jd...@gm...> - 2008-04-14 02:54:46
|
On Sun, Apr 13, 2008 at 9:37 PM, Eric Firing <ef...@ha...> wrote: > John Hunter wrote: > > > On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <ef...@ha...> wrote: > > > > > The present NavigationToolbar2 is very nice, but I am thinking about an > > > improvement: adding a button that would rotate a constraint among three > > > possibilities, so that pan/zoom and rectangle select could be set to > > > affect only X, only Y, or be left unconstrained as at present. > > > > > > > I assume you know that for panning and zooming, if you hold down the > > 'x' key the pan/zoom is constrained in the horizontal direction and if > > you hold down the 'y' key it is constrained to the vertical direction. > > It would not be hard to add support using these keys to the > > zoom-to-rect. Do you think having a toggle button adds more than > > simply using these key presses? > > > > Aha! Evidently I *should* have known, but I *didn't* know, about the x and > y keys. Sounds more and more familiar now, so I'm sure I saw some reference > to it quite a while ago. Strangely, I did not stumble over it yesterday or > today when looking at the code from the standpoint of making the proposed > change. It is mentioned in the tutorial http://matplotlib.sourceforge.net/tutorial.html#toolbar2 and in the "toolbar2" section if the user's guide. There are other nifty nuggets in there, like zoom to point in the zoom mode. > Adding the key support to the zoom-to-rect definitely would help. This seems like a god piece of low hanging fruit. Another feature that a couple of folks have mentioned to me off list would be in an constrained zoom to rect, to have the ylim (optionally) autoscale over the y data in the zoomed region. JDH |
From: Eric F. <ef...@ha...> - 2008-04-14 02:37:16
|
John Hunter wrote: > On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <ef...@ha...> wrote: >> The present NavigationToolbar2 is very nice, but I am thinking about an >> improvement: adding a button that would rotate a constraint among three >> possibilities, so that pan/zoom and rectangle select could be set to >> affect only X, only Y, or be left unconstrained as at present. > > I assume you know that for panning and zooming, if you hold down the > 'x' key the pan/zoom is constrained in the horizontal direction and if > you hold down the 'y' key it is constrained to the vertical direction. > It would not be hard to add support using these keys to the > zoom-to-rect. Do you think having a toggle button adds more than > simply using these key presses? Aha! Evidently I *should* have known, but I *didn't* know, about the x and y keys. Sounds more and more familiar now, so I'm sure I saw some reference to it quite a while ago. Strangely, I did not stumble over it yesterday or today when looking at the code from the standpoint of making the proposed change. The toggle button would make it more obvious that the constraint options exist, and would make the operation easier on my laptop with the trackpad, but it is much less tempting now that you have reminded me of the keys. On the other hand, given that the basic functionality is already there with the keys, it would presumably be easier than I thought to add the button--although Darren doesn't like that interface design, and he may have a good point. Adding the key support to the zoom-to-rect definitely would help. > > I do think Darren's suggestion of making the toolbar more easily > extensible and configurable is a good one. A colleague of mine > recently wanted to change the icons, drop a couple of buttons, and add > a couple of new ones, and I think he ended up just pasting in the code > for NavigationToolbar and modifying what he needed. Not very > attractive from a design persepcetive. I agree entirely that it would be nice if it were easy for a user to pop buttons in or out of the toolbar. I'm glad Darren is interested; it is not something I would be likely to pursue myself. Too hard, with all the gui backends. Eric > > JDH |
From: John H. <jd...@gm...> - 2008-04-14 01:55:51
|
On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <ef...@ha...> wrote: > The present NavigationToolbar2 is very nice, but I am thinking about an > improvement: adding a button that would rotate a constraint among three > possibilities, so that pan/zoom and rectangle select could be set to > affect only X, only Y, or be left unconstrained as at present. I assume you know that for panning and zooming, if you hold down the 'x' key the pan/zoom is constrained in the horizontal direction and if you hold down the 'y' key it is constrained to the vertical direction. It would not be hard to add support using these keys to the zoom-to-rect. Do you think having a toggle button adds more than simply using these key presses? I do think Darren's suggestion of making the toolbar more easily extensible and configurable is a good one. A colleague of mine recently wanted to change the icons, drop a couple of buttons, and add a couple of new ones, and I think he ended up just pasting in the code for NavigationToolbar and modifying what he needed. Not very attractive from a design persepcetive. JDH |
From: Darren D. <dar...@co...> - 2008-04-14 00:24:52
|
Hi Eric, On Sunday 13 April 2008 7:39:14 pm Eric Firing wrote: > The present NavigationToolbar2 is very nice, but I am thinking about an > improvement: adding a button that would rotate a constraint among three > possibilities, so that pan/zoom and rectangle select could be set to > affect only X, only Y, or be left unconstrained as at present. [...] > Although there might be more elegant ways to do it, I think the simplest > way to get this functionality across backends would be to add a single > button that rotates a variable among values of 'X', 'Y', and 'XY', and > then let that variable constrain the effects of pan/zoom and > rectangle-select. I would prefer to not add a button to change the behavior of other buttons, but rather stack three buttons (XY,X,Y) for pan and zoom, perhaps selectable from a drop-down widget of some kind, so you can select which version of pan/zoom you want. > It would be nicer, but more work, to have the > variable change the rubberband to a span-select in the latter case; I am > inclined to start with the easiest implementation I can come up with. I > think the simple approach can be done with only a little bit of change > in the backends. That would be nice, maybe for a future addition. > Comments? Objections? > > This could also be done by making a NavigationToolbar3, but I think that > even with inheritance from NavigationToolbar2, this would require more > work. I recently subclassed NavigationToolbar2 to add a crosshairs button. I have multi-dimensional data and I wanted to click on a point in an image to create an associated projection. I had to reimplement several of the toolbar2 methods with minor changes to support an additional button. I wonder if we could come up with a toolbar that was easier to subclass without reimplementing so much of the machinery. I won't have time to pursue this until summer, just throwing it out there. Darren |
From: Eric F. <ef...@ha...> - 2008-04-13 23:39:30
|
The present NavigationToolbar2 is very nice, but I am thinking about an improvement: adding a button that would rotate a constraint among three possibilities, so that pan/zoom and rectangle select could be set to affect only X, only Y, or be left unconstrained as at present. The problem with the present system is that often one really wants to pan and zoom in only one direction, or at least one direction at a time. For example, I have a dataset consisting of 10000 profile measurements (increasing with time on the X-axis) with 20 vertical bins. I want to display the whole thing with pcolorfast, and then zoom in on particular sections to the point where the individual profiles can be seen clearly. Doing this with the present pan/zoom and rectangle tools is awkward--I am not coordinated enough to move the cursor perfectly horizontally, or to select a rectangle that goes exactly from top to bottom. I suspect that there are many data analysis applications like this, where one wants to vary only one dimension at a time. Although there might be more elegant ways to do it, I think the simplest way to get this functionality across backends would be to add a single button that rotates a variable among values of 'X', 'Y', and 'XY', and then let that variable constrain the effects of pan/zoom and rectangle-select. It would be nicer, but more work, to have the variable change the rubberband to a span-select in the latter case; I am inclined to start with the easiest implementation I can come up with. I think the simple approach can be done with only a little bit of change in the backends. Comments? Objections? This could also be done by making a NavigationToolbar3, but I think that even with inheritance from NavigationToolbar2, this would require more work. Eric |
From: Jarrod M. <mi...@be...> - 2008-04-13 09:58:12
|
On Sat, Apr 12, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote: > On Sat, Apr 12, 2008 at 2:19 PM, Eric Firing <ef...@ha...> wrote: > > and then this was added, as something else that had been agreed at the > > same sprint: > > import pylab as plt > > I think this is a mistake, and it should have been > > > > import matplotlib.pyplot as plt > > This is what we agreed to (import matplotlib.pyplot as plt) during the > numpy sprint (I was on google chat remotely but participated in the > discussion). I agree that pylab as plt would just add to the > confusion. We agreed on promoting (and I currently use) > > > import numpy as np > import scipy as sp > > import matplotlib.pyplot as plt Sorry, that was my mistake. Thanks for clearing it up. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ |
From: John H. <jd...@gm...> - 2008-04-12 22:24:06
|
On Sat, Apr 12, 2008 at 2:19 PM, Eric Firing <ef...@ha...> wrote: > > referring to: > http://news.gmane.org/find-root.php?message_id=%3cc7009a550804100055g6388b20ej520e85d8e679a55%40mail.gmail.com%3e > > There was a slightly jumbled set of threads on Numpy-discussion that > included a discussion of standardizing imports, like this: > > import numpy as np > import scipy as sp > > and then this was added, as something else that had been agreed at the > same sprint: > > import pylab as plt > > I think this is a mistake, and it should have been > > import matplotlib.pyplot as plt This is what we agreed to (import matplotlib.pyplot as plt) during the numpy sprint (I was on google chat remotely but participated in the discussion). I agree that pylab as plt would just add to the confusion. We agreed on promoting (and I currently use) import numpy as np import scipy as sp import matplotlib.pyplot as plt JDH |