matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
> 
>> Getting out a 0.98 beta soon would help in getting it more widely
>> tested, but it would be nice if that first beta passed the basic checks
>> of working for all backend_driver tests on all the standard backends.
>> As of the last time I looked, this was not the case.
> 
> both the branch and the trunk are running w/o error on my system. The
> branch is issuing some warnings related to the new hist changes.
> 
> JDH
They run, but the trunk does not make valid plots in all cases. Many 
things are fouled up in SVG. The quadmesh_demo.ps is broken. I have 
not checked pdf.
Eric

On Wed, May 7, 2008 at 1:21 PM, Eric Firing <ef...@ha...> wrote:
> Getting out a 0.98 beta soon would help in getting it more widely
> tested, but it would be nice if that first beta passed the basic checks
> of working for all backend_driver tests on all the standard backends.
> As of the last time I looked, this was not the case.
both the branch and the trunk are running w/o error on my system. The
branch is issuing some warnings related to the new hist changes.
JDH

I've added get/set_rasterized in Artist.
 The decorator is called @hook_before_after_draw. I wanted to put in a
 mechanism that allowed for registration of before/after draw
 callbacks, but couldn't figure out how. Might still be possible with
 some decorator magic that I don't understand. Each artist with a
 draw(self, renderer) method has been decorated.
 I pulled out the start/stop rendering pair in QuadMesh. I presume
 those two lines were all I needed to touch. I'll assume so unless I
 hear otherwise.
 Patch at:
 http://deeplycloudy.com/patches/20080507-mpl-mixed-mode-decorator-r5110.diff
 (I moved the patch mentioned at the beginning of this thread into the
 patches directory as well.)

John and Michael,
 Thanks for your detailed feedback about the mpl design philosophy. I'm
 not attached to my implementation details. I will scrap the
 draw_raster list and move to implement get/set_rasterized on the
 artists.
 > > Doing this in the axes.draw method may not be the most natural place
 > > to do this since it could be done in the artist.draw method, but it
 > > may be the most expedient. This is an area where having support for
 > > before_draw and after_draw hooks might be useful.
 How about providing a decorator for the draw method that would do the
 necessary check/start/draw/stop? Requires Python 2.4 for the nice
 syntax, but can still be done with 2.3. A decorator would make adding
 the rasterize feature (and others) quite easy for any draw method.
 There are several draw methods in the chain (figure has one, axes has
 one, and line, collections, etc. all do), and this would be a fast,
 low-maintenance way of adding hooks to each artist subclass (I count
 16 2D draw methods). I have a proof-of-concept snippet if it would be
 helpful to understand what I mean.
 > > One potential
 > > problem with either of these approached is it looks like the mixed
 > > mode renderer is set up to handle multiple rasterized draws before
 > > dumping the aggregate image into the backend on a stop_renderer, so
 > > doing the start/stop in any of the approaches above would obviate this
 > > efficiency.
 > > The axes could aggregate the rasterized artists before
 > > rendering and then do them all together, but making this play properly
 > > with zorder will be tricky.
 > >
 > That's right. To receive significant gains, you would generally want to
 > perform a number of drawing operations in a single raster buffer. Given how
 > mpl is currently designed, that generally implies a Collection (which is
 > fairly easy to wrap start/stop_rasterizing calls around) -- it doesn't
 > necessarily have to mean a whole bunch of separate Artist objects (which
 > would be much harder to do given the current way things are drawn). The
 > latter may be ultimately more optimal, but the former is an easy win.
 >
 >
> As for the implementation, Eric's patch does appear to deal with the
 > z-order problem, (by interleaving rasterized and non-rasterized drawing
 > correctly base on zorder), but it doesn't combine adjacent rasterized
 > artists into a single buffer. The drawing loop in Axes.draw could fairly
 > easily be modified to do that. However, I think a better solution that
 > doesn't require an explicit "draw_raster" list, is to make
 > "stop_rasterizing" lazy. At the moment, when "stop_rasterizing" is called,
 > the buffer is immediately flushed and written out. If instead it just set a
 > flag, causing the buffer to be flushed when the next vector object is
 > written, then something like
 >
 > start_rasterizing()
 > draw_line()
 > stop_rastering()
 > start_rastering()
 > draw_line()
 > stop_rasterizing()
 > draw_line()
 >
 > would write out a single raster buffer with two lines, followed by a vector
 > line. Of course, and here is the tricky bit, if the two rasterized objects
 > are really far apart spatially, you waste a lot of space on transparent
 > pixels between them. We can let the user decide whether to rasterize each
 > individually with a nice clean API, but letting the user decide whether to
 > combine adjacent rasterizations gets tricky and I think is asking too much
 > of someone who doesn't know the mpl internals. Perhaps that is an argument
 > against trying to implicitly combine adjacent rasterized draws -- it's
 > trying to be too smart?
 >
 I see the inefficiency in repeated start/stop/flush. At the same
 time, generating a separate image in each start/stop is useful for
 later tweaking/composition in a vector drawing editor. For instance,
 if I overlay points (sometimes 10^5) on top of weather radar data
 (10^5 polys), I might want to turn the points off. So I'd argue that
 flush-per-artist is best because it creates a figure with maximal
 editability, which is one of the advantages of using a vector-based
 backend in the first place.
 In summary:
 1. On the artist base class, add get/set_rasterized( True | False | None )
 with the default for True to be rasterize-per-artist. Later (or now,
 if it's important to others), ('alone' | 'combine') could be added,
 with True defaulting to 'alone'.
 2. Starting / stopping the rasterizing:
> > if a.get_rasterized():
 > > renderer.start_rasterizing()
 > > a.draw(renderer)
 > > renderer.stop_rasterizing()
 > > else:
 > > a.draw(renderer)
 Put this in a draw method decorator. Decorate each artist subclass
individually.
 -Eric

Michael Droettboom wrote:
> I don't know if 0.98 has seen enough hammering to be a recommended 
> stable release. (Just today, Matthias Michler pointed out a pretty 
> significant bug with widgets related to the refactoring). I think a 
> 0.98 release that is clearly labeled as beta would not be a bad thing to 
> get it in the hands of more people who don't track SVN.
> 
Getting out a 0.98 beta soon would help in getting it more widely 
tested, but it would be nice if that first beta passed the basic checks 
of working for all backend_driver tests on all the standard backends. 
As of the last time I looked, this was not the case.
Eric

On Wed, May 7, 2008 at 10:59 AM, Darren Dale <dar...@co...> wrote:
> I'm also in favor of a 0.98 release. Calling it beta is fine, I just need
> something other than svn to which I can point my users.
I happy with both -- doing a 0.91.3 maintenance release and a
0.98.beta release. We don't have to do them at the same time, but it
might be easier. Charlie?
JDH

On Wednesday 07 May 2008 11:18:22 am Michael Droettboom wrote:
> I don't know if 0.98 has seen enough hammering to be a recommended
> stable release. (Just today, Matthias Michler pointed out a pretty
> significant bug with widgets related to the refactoring). I think a
> 0.98 release that is clearly labeled as beta would not be a bad thing to
> get it in the hands of more people who don't track SVN.
I'm also in favor of a 0.98 release. Calling it beta is fine, I just need 
something other than svn to which I can point my users.
Darren

Michael Droettboom wrote:
> I don't know if 0.98 has seen enough hammering to be a recommended 
> stable release. (Just today, Matthias Michler pointed out a pretty 
> significant bug with widgets related to the refactoring). I think a 
> 0.98 release that is clearly labeled as beta would not be a bad thing 
> to get it in the hands of more people who don't track SVN.
>
> I think a 0.91.3 release is probably also in order, since there are 23 
> bugfixes, most notably the wx saving bug. I think that release is 
> important to push bugfixes out to distributions that already package 
> 0.91.2 (e.g. Ubuntu Hardy).
>
> And as for the egg issue (which I'm completely ignorant of) -- is that 
> something that could be fixed on 0.91.x without too much trouble? Is 
> it something that once worked and is now broken?
>
> Cheers,
> Mike
Mike: The egg issue required renaming matplotlib.toolkits to 
mpl_toolkits. We discussed this at the time, and decided it would cause 
too much code breakage to be included in 0.91.x.
I'm OK with a 0.98 beta, but that's more work for Charlie to make extra 
installers and eggs.
-Jeff
>
> Jeff Whitaker wrote:
>> What do people think of releasing 0.98 after numpy 1.1 is released 
>> this weekend?
>> The main reason I'd like to do this (instead of releasing another 
>> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is 
>> installed as an egg basemap (or any other toolkit) cannot be installed.
>>
>> -Jeff
>>
>> 
>
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I don't know if 0.98 has seen enough hammering to be a recommended 
stable release. (Just today, Matthias Michler pointed out a pretty 
significant bug with widgets related to the refactoring). I think a 
0.98 release that is clearly labeled as beta would not be a bad thing to 
get it in the hands of more people who don't track SVN.
I think a 0.91.3 release is probably also in order, since there are 23 
bugfixes, most notably the wx saving bug. I think that release is 
important to push bugfixes out to distributions that already package 
0.91.2 (e.g. Ubuntu Hardy).
And as for the egg issue (which I'm completely ignorant of) -- is that 
something that could be fixed on 0.91.x without too much trouble? Is it 
something that once worked and is now broken?
Cheers,
Mike
Jeff Whitaker wrote:
> What do people think of releasing 0.98 after numpy 1.1 is released this 
> weekend? 
>
> The main reason I'd like to do this (instead of releasing another 
> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is 
> installed as an egg basemap (or any other toolkit) cannot be installed.
>
> -Jeff
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

What do people think of releasing 0.98 after numpy 1.1 is released this 
weekend? 
The main reason I'd like to do this (instead of releasing another 
0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is 
installed as an egg basemap (or any other toolkit) cannot be installed.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

This is not a problem, I compile new nersions of differnet paclages
regularly.
I'll checkout the branch, many thanks !
Matthieu
2008年5月7日 Michael Droettboom <md...@st...>:
> Unfortunately, the fix requires recompiling C code. If you're comfortable
> doing that, the easiest thing is just to check out the svn branch here:
>
> http://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint
>
> But for those not doing that, I think a new release is in order, but I'm
> not the one who normally makes those calls etc.
>
> Cheers,
> Mike
>
> Matthieu Brucher wrote:
>
>>
>>
>> > 2) Use:
>> > F.savefig(open(path, "w"), dpi=dpi)
>> This is exactly what matplotlib the *Agg backends do on the 0.91.x
>> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
>> release) still has this bug. This may be reason enough to push out a
>> new maintenance release of 0.91.x, but I say that having done it
>> before ;)
>>
>>
>> This is a really stopper for me, I have to interact with my figures before
>> saving them, and it is a really annoying behavior.
>> Were should this patch be applied ?
>>
>> +1 for a new maintenance release.
>>
>> I was searching for an answer to this, I'm glad the error was known and
>> the fix available, so thanks :)
>>
>> Matthieu
>> --
>> French PhD student
>> Website : http://matthieu-brucher.developpez.com/
>> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
>> LinkedIn : http://www.linkedin.com/in/matthieubrucher
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Unfortunately, the fix requires recompiling C code. If you're 
comfortable doing that, the easiest thing is just to check out the svn 
branch here:
http://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint
But for those not doing that, I think a new release is in order, but I'm 
not the one who normally makes those calls etc.
Cheers,
Mike
Matthieu Brucher wrote:
>
>
> > 2) Use:
> > F.savefig(open(path, "w"), dpi=dpi)
> This is exactly what matplotlib the *Agg backends do on the 0.91.x
> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
> release) still has this bug. This may be reason enough to push out a
> new maintenance release of 0.91.x, but I say that having done it
> before ;)
>
>
> This is a really stopper for me, I have to interact with my figures 
> before saving them, and it is a really annoying behavior.
> Were should this patch be applied ?
>
> +1 for a new maintenance release.
>
> I was searching for an answer to this, I'm glad the error was known 
> and the fix available, so thanks :)
>
> Matthieu
> -- 
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> Manuel Metz wrote:
>> Hi,
>> while adding the step-histogram I learned about the change of 
>> numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good 
>> idea to switch to the new histogram, i.e. use "new=True". Indeed, this 
>> is required to be able to allow to give bin-edges, which is possible 
>> with MPL 0.91.
>> However, while keeping API compatibility on the one hand by 
>> allowing to provide bin-edges, this step also breaks API compatibility 
>> since the definition of bins has changed:
>>
>> numpy 1.0.4
>>
>> In [1]:from numpy import *
>> In [2]:random.seed(18)
>> In [3]:x = random.random(100)
>> In [4]:histogram(x, bins=array([0,0.1,0.2]))
>> Out[4]:(array([11, 11, 78]), array([ 0. , 0.1, 0.2]))
>>
>> numpy 1.1.0.dev5106'
>>
>> In [1]:from numpy import *
>> In [2]:random.seed(18)
>> In [3]:x = random.random(100)
>> In [4]: histogram(x, bins=array([0,0.1,0.2]),new=True)
>> Out[4]: (array([11, 11]), array([ 0. , 0.1, 0.2]))
>>
>>
>> How should this be handled? Follow numpy, breaking API compatibility 
>> and point to the API change of histogram? Or keeping API compatibility 
>> with MPL0.91 and write a wrapper function?
>>
>> I would prefer the first option...
> 
> I strongly agree.
> 
> Eric
> 
Hi,
so, I just commited the patch and also updated the API_CHANGES file.
Manuel

John Hunter schrieb:
> On Tue, May 6, 2008 at 8:49 AM, Gregor Thalhammer
> <gre...@gm...> wrote:
>
> 
>> I also discovered this behaviour. It seems to be a Windows only specific
>> behaviour that only affects the bitmaps of the disabled (or grayed out)
>> toolbar buttons. A solution I found is to use the png toolbar bitmaps
>> instead of of the xpm ones. For this, replace in backend_wx.py,
>> NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the
>> same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by
>> wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png
>> bitmaps have an alpha channel, see attached file. Furthermore, in my
>> opinion, the floppy symbol is too small compared to the other icons. I also
>> attached a magnified version.
>> 
>
> Thankso Gregor -- I made these changes XPM->PNG for toolbar2 on the
> svn branch and trunk, but I don't have ready access to wx here, so if
> you or another wx svn user gets a chance to check, that would be
> great. Else I can do it tonight from home.
>
> 
I checked the svn version (on Linux), works well. On Windows, applying 
these changes manually, I could see grayed out toolbox icons.
Gregor

>
>
> > 2) Use:
> > F.savefig(open(path, "w"), dpi=dpi)
> This is exactly what matplotlib the *Agg backends do on the 0.91.x
> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
> release) still has this bug. This may be reason enough to push out a
> new maintenance release of 0.91.x, but I say that having done it before ;)
This is a really stopper for me, I have to interact with my figures before
saving them, and it is a really annoying behavior.
Were should this patch be applied ?
+1 for a new maintenance release.
I was searching for an answer to this, I'm glad the error was known and the
fix available, so thanks :)
Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher