matplotlib-devel Mailing List for matplotlib (Page 3)

It's possible -- the version of freetype in the win32_static.tar.gz 
package is 2.1.7.  I have 2.1.9 on my (working) Linux box.  Perhaps 
something between those point releases fixes this bug.  But it could be 
a lot of other things, too.

I'm going to file a bug for this so it doesn't get lost.

Cheers,
Mike

Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> Thanks.  Unfortunately, I'm not able to reproduce any problems with 
>> the font on Linux (see attached).  I suspect the problem may be 
>> Windows-specific, but I have no way of knowing at the moment.  I'll 
>> have to try this at home (no Windows at work), or maybe one of the 
>> other Windows gurus on this list wants to take it up.
>>
> 
> Could it be that the static compile libraries needs to be updated? I 
> rely on the precompiled versions.
> 
> /Jörgen

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom skrev:
> Thanks.  Unfortunately, I'm not able to reproduce any problems with the 
> font on Linux (see attached).  I suspect the problem may be 
> Windows-specific, but I have no way of knowing at the moment.  I'll have 
> to try this at home (no Windows at work), or maybe one of the other 
> Windows gurus on this list wants to take it up.
> 

Could it be that the static compile libraries needs to be updated? I 
rely on the precompiled versions.

/Jörgen

Michael Droettboom wrote:
> or maybe one of the other 
> Windows gurus on this list wants to take it up.

I shouldn't have said "other".  I don't consider myself a guru of much 
of anything ;)

Cheers,
Mike

Thanks.  Unfortunately, I'm not able to reproduce any problems with the 
font on Linux (see attached).  I suspect the problem may be 
Windows-specific, but I have no way of knowing at the moment.  I'll have 
to try this at home (no Windows at work), or maybe one of the other 
Windows gurus on this list wants to take it up.

Cheers,
Mike

Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> Is the font freely available, and if so, can you provide a link?  I'd 
>> like to find a workaround if possible -- one shouldn't have to remove 
>> fonts just to run matplotlib.
>>
> You can download it from 
> <http://www.tradebit.com/filedetail.php/1893643-Software-Programs-Utilities> 
> 
> 
> I did a md5sum on the orlando font I had and it was the same. The 
> zipfile from download also contained a bold version which I didn't have 
> before. But both versions cause the same problem.
> 
> /Jörgen

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom skrev:
> Is the font freely available, and if so, can you provide a link?  I'd 
> like to find a workaround if possible -- one shouldn't have to remove 
> fonts just to run matplotlib.
> 
You can download it from 
<http://www.tradebit.com/filedetail.php/1893643-Software-Programs-Utilities>

I did a md5sum on the orlando font I had and it was the same. The 
zipfile from download also contained a bold version which I didn't have 
before. But both versions cause the same problem.

/Jörgen

That did it, thanks Mike.

On Tuesday 22 January 2008 08:09:37 am Michael Droettboom wrote:
> Thanks.  The "ignore existing data" flag was not getting set properly.
>
> Fixed in r4884.  Please let me know how that works for you.
>
> Cheers,
> Mike
>
> Darren Dale wrote:
> > In the trunk, I noticed that relim() followed by autoscale_view() do not
> > have the same behavior as they did with the old transforms branch. For
> > example:
> >
> > l,=plot([1,2,3])
> > l.set_ydata([4,5,6])
> > gca().relim()
> > gca().autoscale_view()
> > draw()
> >
> > used to produce the same output as
> >
> > plot([4,5,6])
> >
> > but now it is equivalent to
> >
> > plot([4,5,6])
> > ylim(1,6)
> >
> > Darren
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

Thanks.  The "ignore existing data" flag was not getting set properly.

Fixed in r4884.  Please let me know how that works for you.

Cheers,
Mike

Darren Dale wrote:
> In the trunk, I noticed that relim() followed by autoscale_view() do not have 
> the same behavior as they did with the old transforms branch. For example:
> 
> l,=plot([1,2,3])
> l.set_ydata([4,5,6])
> gca().relim()
> gca().autoscale_view()
> draw()
> 
> used to produce the same output as
> 
> plot([4,5,6])
> 
> but now it is equivalent to 
> 
> plot([4,5,6])
> ylim(1,6)
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

Is the font freely available, and if so, can you provide a link?  I'd 
like to find a workaround if possible -- one shouldn't have to remove 
fonts just to run matplotlib.

Cheers,
Mike

Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> I haven't seen this issue.  It may just be a dirty compilation 
>> problem.   Often distutils doesn't rebuild enough.  Try removing the 
>> build directory and then build/install.
>>
>> If that's not the case, we'll need to track down which font is 
>> tripping it up.  Set "verbose.level" to "debug-annoying" and then send 
>> us the output.
>>
> I get the crash on font orlando.ttf. If I delete this font there is no 
> crash.
> 
> /Jörgen

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

In the trunk, I noticed that relim() followed by autoscale_view() do not have 
the same behavior as they did with the old transforms branch. For example:

l,=plot([1,2,3])
l.set_ydata([4,5,6])
gca().relim()
gca().autoscale_view()
draw()

used to produce the same output as

plot([4,5,6])

but now it is equivalent to 

plot([4,5,6])
ylim(1,6)

Darren

Michael Droettboom skrev:
> I haven't seen this issue.  It may just be a dirty compilation problem. 
>   Often distutils doesn't rebuild enough.  Try removing the build 
> directory and then build/install.
> 
> If that's not the case, we'll need to track down which font is tripping 
> it up.  Set "verbose.level" to "debug-annoying" and then send us the output.
> 
I get the crash on font orlando.ttf. If I delete this font there is no 
crash.

/Jörgen

Michael Droettboom wrote:
> Thanks for finding this.
> 
> This should be fixed in r4881.  It was a simple reference counting bug.
> 
> Please let me know if you still see leaks.

That fixed it here.  Thank you!

Eric

I haven't seen this issue.  It may just be a dirty compilation problem. 
  Often distutils doesn't rebuild enough.  Try removing the build 
directory and then build/install.

If that's not the case, we'll need to track down which font is tripping 
it up.  Set "verbose.level" to "debug-annoying" and then send us the output.

Cheers,
Mike

Jörgen Stenarson wrote:
> Hi
> 
> today after upgrading to the latest svn (r4880 compiled with mingw) and 
> deleting fontManager.cache I got the following message and a crash
> 
> c:\python\>python
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import pylab
> Assertion failed: ob_refcnt == 0, file CXX\cxx_extensions.cxx, line 1128
> 
> This application has requested the Runtime to terminate it in an unusual 
> way.
> Please contact the application's support team for more information.
> 
> restoring my old fontManager.cache I can successfully use matplotlib.
> 
> c:\python\>python
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import pylab
>  >>>
> 
> 
> I tried backdating matplotlib 40 revisions and got the same result. So 
> it is not a new problem.
> 
> Any one else seeing this?
> 
> /Jörgen
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

Thanks for finding this.

This should be fixed in r4881.  It was a simple reference counting bug.

Please let me know if you still see leaks.

Cheers,
Mike

Eric Firing wrote:
> Rob Hetland wrote:
>> I am using the new transforms version of MPL (the svn trunk), and  
>> found a memory leak in pcolor and pcolormesh.  Be warned, I just  
>> reported a memory leak in the scikits delaunay package that Robert  
>> Kern was not able to reproduce, so it might be nice if someone could  
>> check this out.  I am on Mac OS X, 10.4 using the latest svn versions  
>> of numpy and mpl.  Here is the code that shows the leak:
>>
> 
> I have confirmed this on linux.
> 
> Eric
> 
>> from pylab import figure, close, ioff, savefig
>> from numpy.random import rand
>>
>>
>> ioff()
>>
>> for n in range(1000):
>>      fig = figure()
>>      ax = fig.add_subplot(111)
>>      data = rand(1000, 1000)
>>      ax.pcolormesh(data)
>>      savefig('foo.png')
>>      close(fig)
>>      print n
>>
>>
>>
>> I get over a gig in real and virtual memory (over 2 gig total) by  
>> n=30.  I tried both pcolor and pcolormesh, as well as deleting  
>> various objects, clearing the axis, etc.
>>
>> -Rob
>>
>> ----
>> Rob Hetland, Associate Professor
>> Dept. of Oceanography, Texas A&M University
>> http://pong.tamu.edu/~rob
>> phone: 979-458-0096, fax: 979-845-6331
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

Hi

today after upgrading to the latest svn (r4880 compiled with mingw) and 
deleting fontManager.cache I got the following message and a crash

c:\python\>python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Assertion failed: ob_refcnt == 0, file CXX\cxx_extensions.cxx, line 1128

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.

restoring my old fontManager.cache I can successfully use matplotlib.

c:\python\>python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
 >>>


I tried backdating matplotlib 40 revisions and got the same result. So 
it is not a new problem.

Any one else seeing this?

/Jörgen

Rob Hetland wrote:
> I am using the new transforms version of MPL (the svn trunk), and  
> found a memory leak in pcolor and pcolormesh.  Be warned, I just  
> reported a memory leak in the scikits delaunay package that Robert  
> Kern was not able to reproduce, so it might be nice if someone could  
> check this out.  I am on Mac OS X, 10.4 using the latest svn versions  
> of numpy and mpl.  Here is the code that shows the leak:
> 

I have confirmed this on linux.

Eric

> 
> from pylab import figure, close, ioff, savefig
> from numpy.random import rand
> 
> 
> ioff()
> 
> for n in range(1000):
>      fig = figure()
>      ax = fig.add_subplot(111)
>      data = rand(1000, 1000)
>      ax.pcolormesh(data)
>      savefig('foo.png')
>      close(fig)
>      print n
> 
> 
> 
> I get over a gig in real and virtual memory (over 2 gig total) by  
> n=30.  I tried both pcolor and pcolormesh, as well as deleting  
> various objects, clearing the axis, etc.
> 
> -Rob
> 
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I am using the new transforms version of MPL (the svn trunk), and  
found a memory leak in pcolor and pcolormesh.  Be warned, I just  
reported a memory leak in the scikits delaunay package that Robert  
Kern was not able to reproduce, so it might be nice if someone could  
check this out.  I am on Mac OS X, 10.4 using the latest svn versions  
of numpy and mpl.  Here is the code that shows the leak:


from pylab import figure, close, ioff, savefig
from numpy.random import rand


ioff()

for n in range(1000):
     fig = figure()
     ax = fig.add_subplot(111)
     data = rand(1000, 1000)
     ax.pcolormesh(data)
     savefig('foo.png')
     close(fig)
     print n



I get over a gig in real and virtual memory (over 2 gig total) by  
n=30.  I tried both pcolor and pcolormesh, as well as deleting  
various objects, clearing the axis, etc.

-Rob

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Jeez ... OK, a second try without mentioning the word. (to evade the spam
filters).

Browsing the matplotlib wiki topical software page tonight I stumbled across
a link to "that drug that men can use when they need some help below the
waistline .... starts with the letter V"  placed next to a topic link. A
page search revealed many more of the same. I hope whoever manages this page
can clean it up. (btw - thanks for an awesome python package). cya

I have this "line simplification" stuff ported to the trunk.  I've 
avoided the issues of bezier curves, compound polygons etc. for now -- 
the simplification will run only for simple series of line segments 
without fill.  Chances are that if polygons or curves are being used, 
the number of vertices is relatively low anyway.  I have yet to see a 
use case for a sequence of 100,000 bezier curves -- heck, it wasn't even 
possible in 0.91.2.

The results are quite good (see attached plots).  GtkAgg scales 
approximately as well as 0.91.2 now, and Gtk is significantly better 
since it now takes advantage of line simplification (where it didn't 
before).

One caveat -- the benchmark I used is probably better than average for 
real data, since it uses a sampled sine wave, which is "smoother" than 
most real world data probably is, leaving lots of opportunities for line 
simplification.  Time permitting, I might run the benchmark on random 
noise and see if there are significant differences.  I would affect the 
performance to fall of faster in that case.

Cheers,
Mike

Michael Droettboom wrote:
> Quick status update, and moving to matplotlib-devel, since I think this 
> is no longer relevant to the OP --
> 
> The difference seems to be due to the simplification/clipping/decimation 
> loop in the old draw_lines.  It appears that even when you have a sine 
> wave line plotted with 100,000 points, only 75 of them actually end up 
> being sent to Agg.  Valgrind's callgrind tells me that most of the time 
> spent on the trunk when you have many line segments is spent stroking 
> the line.  So, clearly, drastically reducing the number of line segments 
> should help immensely.
> 
> When I made the conversion from draw_lines to everything using 
> draw_path, I had skipped over the simplification step because a) the 
> problem is a little harder with general polycurves (since you can't stop 
> in the middle of a curve) and b) I had assumed, with no evidence, that 
> Agg would be doing some of this anyway.
> 
> So, I'm in the process of porting the big loop in draw_lines over to the 
> trunk.  It's complicated by curve problem and the desire to avoid a 
> copy, of course, but it should be doable.  There's probably a cross-over 
> point at which the time spent simplifying the line becomes less than the 
> time spent stroking the line.  That will probably have to be arrived at 
> by experimentation.
> 
> Cheers,
> Mike
> 
> Michael Droettboom wrote:
>> John Hunter wrote:
>>> On Jan 15, 2008 7:46 AM, Michael Droettboom <md...@st...> wrote:
>>>> Ah -- just thought of something else.
>>>>
>>>> If I adjust simple_plot_fps.py to have 100,000 data points rather than
>>>> 1,000 I see something that starts to match with what you're seeing:
>>>>
>>>> GtkAgg:
>>>> wallclock: 4.23297405243
>>>> user: 3.33
>>>> fps: 23.6240522057
>>>>
>>>> Gtk:
>>>> wallclock: 15.0203828812
>>>> user: 14.92
>>>> fps: 6.65761990165
>>>>
>>>> TkAgg:
>>>> wallclock: 4.8252530098
>>>> user: 4.67
>>>> fps: 20.7243018754
>>>>
>>>> You can see that the Gtk time is starting to explode.  If I go to
>>>> 1,000,000 points, Gtk runs out of memory before the first plot, whereas
>>>> the other two continue to chug along at a reasonable pace.
>>>>
>>>>  From looking at the code, I suspect the crucial difference is that the
>>>> Gdk backend uses the Python sequence API (rather slow) to access the
>>>> data as it gets rendered, whereas GtkAgg uses the numpy array interface
>>>> which is essentially raw access to a C array.
>>> This is not likely to be the culprit -- for drawing markers, the old
>>> matplotlib API made a separate call to draw_polygon for every marker,
>>> with a new gc each time.  Many moons ago, we implemented draw_markers
>>> as a renderer method to avoid this problem.  For hundreds of thousands
>>> of markers, we saw performance benefits of 25x to 100x.  The backends
>>> which implement draw_markers (Agg and PS) get the benefits, but the
>>> other backends which did not are still slow. Basically it is a problem
>>> with a lot of redundant function call overhead.   The backend_bases
>>> renderer method _draw_markers discusses this a little bit (it is
>>> underscore hidden).
>> Markers are not the issue here.  These benchmarks were done with lines. 
>>   There are markers for the ticks, of course, but the number of those 
>> are fixed.  I agree it's function call overhead, but I believe it's in 
>> the overhead of PySequence_GetItem vs. array[index].  In both cases, the 
>> line is still getting drawn with a single Python -> C function call.
>>
>>> My guess is this difference will not be so pronounced on the trunk.
>> Actually, I'm getting surprising results there.  Numbers are in fps.
>>
>> 				Gtk		GtkAgg	
>> 0.91.2, 1000 points		50		26
>> 0.91.2, 10000 points		6		23
>> trunk, 1000 points		38		31
>> trunk, 10000 points		3		9
>>
>> So, yes, the ratio between Gtk and GtkAgg on the trunk is not as 
>> pronounced.  I'm a little disappointed by the timings on the trunk -- 
>> while one could say that Agg is a little better on the trunk with 1000 
>> points, it doesn't scale nearly as well.  That's certainly something to 
>> look into -- and I don't have any thoughts offhand.  I would expect the 
>> trunk to do better since it doesn't perform a memory copy on the data 
>> with each call to draw_line/draw_path.
>>
>> Cheers,
>> Mike
>>
> 

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Quick status update, and moving to matplotlib-devel, since I think this 
is no longer relevant to the OP --

The difference seems to be due to the simplification/clipping/decimation 
loop in the old draw_lines.  It appears that even when you have a sine 
wave line plotted with 100,000 points, only 75 of them actually end up 
being sent to Agg.  Valgrind's callgrind tells me that most of the time 
spent on the trunk when you have many line segments is spent stroking 
the line.  So, clearly, drastically reducing the number of line segments 
should help immensely.

When I made the conversion from draw_lines to everything using 
draw_path, I had skipped over the simplification step because a) the 
problem is a little harder with general polycurves (since you can't stop 
in the middle of a curve) and b) I had assumed, with no evidence, that 
Agg would be doing some of this anyway.

So, I'm in the process of porting the big loop in draw_lines over to the 
trunk.  It's complicated by curve problem and the desire to avoid a 
copy, of course, but it should be doable.  There's probably a cross-over 
point at which the time spent simplifying the line becomes less than the 
time spent stroking the line.  That will probably have to be arrived at 
by experimentation.

Cheers,
Mike

Michael Droettboom wrote:
> 
> John Hunter wrote:
>> On Jan 15, 2008 7:46 AM, Michael Droettboom <md...@st...> wrote:
>>> Ah -- just thought of something else.
>>>
>>> If I adjust simple_plot_fps.py to have 100,000 data points rather than
>>> 1,000 I see something that starts to match with what you're seeing:
>>>
>>> GtkAgg:
>>> wallclock: 4.23297405243
>>> user: 3.33
>>> fps: 23.6240522057
>>>
>>> Gtk:
>>> wallclock: 15.0203828812
>>> user: 14.92
>>> fps: 6.65761990165
>>>
>>> TkAgg:
>>> wallclock: 4.8252530098
>>> user: 4.67
>>> fps: 20.7243018754
>>>
>>> You can see that the Gtk time is starting to explode.  If I go to
>>> 1,000,000 points, Gtk runs out of memory before the first plot, whereas
>>> the other two continue to chug along at a reasonable pace.
>>>
>>>  From looking at the code, I suspect the crucial difference is that the
>>> Gdk backend uses the Python sequence API (rather slow) to access the
>>> data as it gets rendered, whereas GtkAgg uses the numpy array interface
>>> which is essentially raw access to a C array.
>> This is not likely to be the culprit -- for drawing markers, the old
>> matplotlib API made a separate call to draw_polygon for every marker,
>> with a new gc each time.  Many moons ago, we implemented draw_markers
>> as a renderer method to avoid this problem.  For hundreds of thousands
>> of markers, we saw performance benefits of 25x to 100x.  The backends
>> which implement draw_markers (Agg and PS) get the benefits, but the
>> other backends which did not are still slow. Basically it is a problem
>> with a lot of redundant function call overhead.   The backend_bases
>> renderer method _draw_markers discusses this a little bit (it is
>> underscore hidden).
> 
> Markers are not the issue here.  These benchmarks were done with lines. 
>   There are markers for the ticks, of course, but the number of those 
> are fixed.  I agree it's function call overhead, but I believe it's in 
> the overhead of PySequence_GetItem vs. array[index].  In both cases, the 
> line is still getting drawn with a single Python -> C function call.
> 
>> My guess is this difference will not be so pronounced on the trunk.
> 
> Actually, I'm getting surprising results there.  Numbers are in fps.
> 
> 				Gtk		GtkAgg	
> 0.91.2, 1000 points		50		26
> 0.91.2, 10000 points		6		23
> trunk, 1000 points		38		31
> trunk, 10000 points		3		9
> 
> So, yes, the ratio between Gtk and GtkAgg on the trunk is not as 
> pronounced.  I'm a little disappointed by the timings on the trunk -- 
> while one could say that Agg is a little better on the trunk with 1000 
> points, it doesn't scale nearly as well.  That's certainly something to 
> look into -- and I don't have any thoughts offhand.  I would expect the 
> trunk to do better since it doesn't perform a memory copy on the data 
> with each call to draw_line/draw_path.
> 
> Cheers,
> Mike
> 

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jan 2, 2008 12:53 PM, Gurz=F3 P=E9ter <gu...@gm...> wrote:

> i think in print_png we must use "str(filename)" as we do it in
> print_raw, not "filename".

Added in maintenance branch and trunk -- thanks.

JDH

Eric Firing wrote:
> Jeff Whitaker wrote:
>> Ted Drain wrote:
>>> Could someone point me at a discussion/article that explains the 
>>> need for namespace packages?  I'm sure there is some good reason for 
>>> it but on the surface it seems very confusing.  I've always thought 
>>> that the purpose of the __init__ file is to define the public 
>>> interface for a package.  So when you say:
>>>
>>> import foo
>>>
>>> You get foo defined in the way it should be.  I'm not sure how doing :
>>>
>>> import foo.api as foo
>>>
>>> is an improvement.  Whether the api is defined in __init__.py or 
>>> api.py doesn't seem to matter (though I'm sure this is where I'm not 
>>> understanding things...).  I've googled and found references to 
>>> needing to install and distribute sub-packages separately but that 
>>> doesn't really seem to explain why __init__ can't be used in the 
>>> sub-package.  Is this primarily a limitation in the distribution and 
>>> setup tools?
>>>
>>> Can someone shed some light on this for me?
>>>
>>> Ted
>>
>> Ted: I was wrong in my previous email - only the __init__.py in the 
>> top-level toolkits directory (now called mpl_toolkits) needs to be 
>> empty.  So in the case of basemap, this means that the import has 
>> changed from
>>
>> from matplotlib.toolkits.basemap import Basemap
>>
>> to
>>
>> from mpl_toolkits.basemap import Basemap.
>>
>> We don't actually need to stuff things into an api.py file.
>
> But the reason you had to move to an independent mpl_toolkits package 
> (which is a namespace package) is because mpl itself can't be a 
> namespace package, because it has an __init__.py stuffed full of 
> goodies.  Right?  Not that having an independent mpl_toolkits is a bad 
> thing; it may make sense anyway.  I think it simplifies the directory 
> structure of basemap (which seemed needlessly deeply nested), doesn't it?

Eric:  Yes, you're correct on both counts.
>
> Also, the namespace package constraint is inherent in distributing 
> subpackages as eggs, correct?  Without eggs there would be no such 
> constraint.  Subpackages would physically land in subdirectories of 
> the main package upon installation.

Right again. 

-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

Jeff Whitaker wrote:
> Ted Drain wrote:
>> Could someone point me at a discussion/article that explains the need 
>> for namespace packages?  I'm sure there is some good reason for it but 
>> on the surface it seems very confusing.  I've always thought that the 
>> purpose of the __init__ file is to define the public interface for a 
>> package.  So when you say:
>>
>> import foo
>>
>> You get foo defined in the way it should be.  I'm not sure how doing :
>>
>> import foo.api as foo
>>
>> is an improvement.  Whether the api is defined in __init__.py or 
>> api.py doesn't seem to matter (though I'm sure this is where I'm not 
>> understanding things...).  I've googled and found references to 
>> needing to install and distribute sub-packages separately but that 
>> doesn't really seem to explain why __init__ can't be used in the 
>> sub-package.  Is this primarily a limitation in the distribution and 
>> setup tools?
>>
>> Can someone shed some light on this for me?
>>
>> Ted
> 
> Ted: I was wrong in my previous email - only the __init__.py in the 
> top-level toolkits directory (now called mpl_toolkits) needs to be 
> empty.  So in the case of basemap, this means that the import has 
> changed from
> 
> from matplotlib.toolkits.basemap import Basemap
> 
> to
> 
> from mpl_toolkits.basemap import Basemap.
> 
> We don't actually need to stuff things into an api.py file.

But the reason you had to move to an independent mpl_toolkits package 
(which is a namespace package) is because mpl itself can't be a 
namespace package, because it has an __init__.py stuffed full of 
goodies.  Right?  Not that having an independent mpl_toolkits is a bad 
thing; it may make sense anyway.  I think it simplifies the directory 
structure of basemap (which seemed needlessly deeply nested), doesn't it?

Also, the namespace package constraint is inherent in distributing 
subpackages as eggs, correct?  Without eggs there would be no such 
constraint.  Subpackages would physically land in subdirectories of the 
main package upon installation.

Eric

Ted Drain wrote:
> Could someone point me at a discussion/article that explains the need 
> for namespace packages?  I'm sure there is some good reason for it but 
> on the surface it seems very confusing.  I've always thought that the 
> purpose of the __init__ file is to define the public interface for a 
> package.  So when you say:
>
> import foo
>
> You get foo defined in the way it should be.  I'm not sure how doing :
>
> import foo.api as foo
>
> is an improvement.  Whether the api is defined in __init__.py or 
> api.py doesn't seem to matter (though I'm sure this is where I'm not 
> understanding things...).  I've googled and found references to 
> needing to install and distribute sub-packages separately but that 
> doesn't really seem to explain why __init__ can't be used in the 
> sub-package.  Is this primarily a limitation in the distribution and 
> setup tools?
>
> Can someone shed some light on this for me?
>
> Ted

Ted: I was wrong in my previous email - only the __init__.py in the 
top-level toolkits directory (now called mpl_toolkits) needs to be 
empty.  So in the case of basemap, this means that the import has 
changed from

from matplotlib.toolkits.basemap import Basemap

to

from mpl_toolkits.basemap import Basemap.

We don't actually need to stuff things into an api.py file.

-Jeff
>
> At 08:11 AM 1/10/2008, Jeff Whitaker wrote:
>> Andrew Straw wrote:
>> > Great -- hopefully that saved you some API re-arrangement pain. No
>> > problem on shuffling mpl_sizer around -- please go ahead do it if you
>> > have time.
>> >
>> > -Andrew
>> >
>> > Jeff Whitaker wrote:
>> >> Andrew:  Thanks, you've convinced me.  Is it OK with you if I go
>> >> ahead and make those changes to mplsizer at the same time I do 
>> basemap?
>> >>
>> >> -Jeff
>> >>
>> >
>> Andrew:  OK, the change to mpl_toolkits (which is now a proper namespace
>> package) is all done.
>>
>> -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
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace 
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel 
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


-- 
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

Could someone point me at a discussion/article that explains the need 
for namespace packages?  I'm sure there is some good reason for it 
but on the surface it seems very confusing.  I've always thought that 
the purpose of the __init__ file is to define the public interface 
for a package.  So when you say:

import foo

You get foo defined in the way it should be.  I'm not sure how doing :

import foo.api as foo

is an improvement.  Whether the api is defined in __init__.py or 
api.py doesn't seem to matter (though I'm sure this is where I'm not 
understanding things...).  I've googled and found references to 
needing to install and distribute sub-packages separately but that 
doesn't really seem to explain why __init__ can't be used in the 
sub-package.  Is this primarily a limitation in the distribution and 
setup tools?

Can someone shed some light on this for me?

Ted

At 08:11 AM 1/10/2008, Jeff Whitaker wrote:
>Andrew Straw wrote:
> > Great -- hopefully that saved you some API re-arrangement pain. No
> > problem on shuffling mpl_sizer around -- please go ahead do it if you
> > have time.
> >
> > -Andrew
> >
> > Jeff Whitaker wrote:
> >> Andrew:  Thanks, you've convinced me.  Is it OK with you if I go
> >> ahead and make those changes to mplsizer at the same time I do basemap?
> >>
> >> -Jeff
> >>
> >
>Andrew:  OK, the change to mpl_toolkits (which is now a proper namespace
>package) is all done.
>
>-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
>
>
>-------------------------------------------------------------------------
>Check out the new SourceForge.net Marketplace.
>It's the best place to buy or sell services for
>just about anything Open Source.
>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Andrew Straw wrote:
> Great -- hopefully that saved you some API re-arrangement pain. No 
> problem on shuffling mpl_sizer around -- please go ahead do it if you 
> have time.
>
> -Andrew
>
> Jeff Whitaker wrote:
>> Andrew:  Thanks, you've convinced me.  Is it OK with you if I go 
>> ahead and make those changes to mplsizer at the same time I do basemap?
>>
>> -Jeff
>>
>
Andrew:  OK, the change to mpl_toolkits (which is now a proper namespace 
package) is all done.

-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