matplotlib-devel Mailing List for matplotlib (Page 8)

On Fri, Nov 09, 2007 at 01:39:10PM -0600, John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> 
> > I've committed my changes on the transforms branch so you can play with
> > it -- I'm holding off on changing the trunk due to the pending release.
> > But if everyone agrees on the way to expose this, it would be nice to
> > merge this over to trunk before the release.
> 
> Am I right in assuming that the only thing we lose in this approach is
> faceting (which Eric hates but others may care about)? Since it is
> orders of magnitudes faster, we could have a pcolor_faceted which
> pcolor calls the old function if shading='faceted'. Of course the two
> functions would return different types (image vs patch collection)
> which is potentially a bit confusing.... We could play with adding
> faceting to images....
It is important for us that the entire cell have the same colour.
Is this what you get with shading='flat'? 
Sometimes shading='faceted' is useful. You should be able to do this
faster by simply blasting an array of lines over top of shading='flat'
than by drawing each individual quadrilateral.
Note that I found 'faceted' to be much nicer when the lines are drawn
with transparency. Without transparency, a large array turns the
entire image black --- not very useful.
 - Paul

Mike,
Thank you for once again blasting out such an array of improvements.
Regarding implementation and API details, such as what should go in 
imshow versus pcolor versus something with another name, I would like to 
review the situation (and your branch) and come up with a 
recommendation, but I can't do it immediately. I can have something 
waiting for you on Monday morning, however.
(But very briefly, an initial thought: an image is a very special 
"thing", and I am reluctant to overload imshow. We may do best to have 
separate methods for each distinctly separate case. That can keep both 
API and implementation simpler than trying to cram too many variations 
into a single method or function.)
(Arg! This brings up the *big* question of what should be a class, and 
how much functionality, and what kind, should be stuffed into axes methods.)
Eric
Michael Droettboom wrote:
> John Hunter wrote:
>> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
>>
>>> I've committed my changes on the transforms branch so you can play with
>>> it -- I'm holding off on changing the trunk due to the pending release.
>>> But if everyone agrees on the way to expose this, it would be nice to
>>> merge this over to trunk before the release.
>>
>> Am I right in assuming that the only thing we lose in this approach is
>> faceting (which Eric hates but others may care about)? Since it is
>> orders of magnitudes faster, we could have a pcolor_faceted which
>> pcolor calls the old function if shading='faceted'. Of course the two
>> functions would return different types (image vs patch collection)
>> which is potentially a bit confusing.... We could play with adding
>> faceting to images....
> 
> pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses 
> pcolor), where the edges of the quadrilaterals are not necessarily 
> parallel to the x or y axes. The NonUniformImage stuff requires that 
> the quadrilaterals are axis-aligned rectangles. To put it another way, 
> the X and Y arrays (that define the mesh) can be 2-dimensional for 
> pcolor, but only 1-dimensional for (the new) imshow.
> 
> pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, 
> but uses optimized quadmesh drawing under the hood, rather than a 
> PolyCollection. (Though the comments hint at subtle differences related 
> to masking.)
> 
> But you are right -- NonUniformImage does not support outlining each 
> quadrilateral -- though that may not be hard to add if needed.
> 
> The difference in return types is perhaps an argument for 
> NonUniformImages going in imshow, not pcolor. (I was thinking only of 
> ease of implementation...)
> 
> Cheers,
> Mike
> 

John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> 
>> I've committed my changes on the transforms branch so you can play with
>> it -- I'm holding off on changing the trunk due to the pending release.
>> But if everyone agrees on the way to expose this, it would be nice to
>> merge this over to trunk before the release.
> 
> Am I right in assuming that the only thing we lose in this approach is
> faceting (which Eric hates but others may care about)? Since it is
John, I agree that others may want faceting, but I have not yet heard 
from anyone who does. When I proposed making "flat" the default I got 
only positive comments, and there have been no complaints about the change.
> orders of magnitudes faster, we could have a pcolor_faceted which
> pcolor calls the old function if shading='faceted'. Of course the two
> functions would return different types (image vs patch collection)
> which is potentially a bit confusing.... We could play with adding
> faceting to images....
Not worth the trouble; retaining an old-style pcolor with faceting that 
can be turned on is good enough support for the faceted use case--if 
anyone is even using it.
Eric

John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> 
>> I've committed my changes on the transforms branch so you can play with
>> it -- I'm holding off on changing the trunk due to the pending release.
>> But if everyone agrees on the way to expose this, it would be nice to
>> merge this over to trunk before the release.
> 
> Am I right in assuming that the only thing we lose in this approach is
> faceting (which Eric hates but others may care about)? Since it is
> orders of magnitudes faster, we could have a pcolor_faceted which
> pcolor calls the old function if shading='faceted'. Of course the two
> functions would return different types (image vs patch collection)
> which is potentially a bit confusing.... We could play with adding
> faceting to images....
pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses 
pcolor), where the edges of the quadrilaterals are not necessarily 
parallel to the x or y axes. The NonUniformImage stuff requires that 
the quadrilaterals are axis-aligned rectangles. To put it another way, 
the X and Y arrays (that define the mesh) can be 2-dimensional for 
pcolor, but only 1-dimensional for (the new) imshow.
pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, 
but uses optimized quadmesh drawing under the hood, rather than a 
PolyCollection. (Though the comments hint at subtle differences related 
to masking.)
But you are right -- NonUniformImage does not support outlining each 
quadrilateral -- though that may not be hard to add if needed.
The difference in return types is perhaps an argument for 
NonUniformImages going in imshow, not pcolor. (I was thinking only of 
ease of implementation...)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> I've committed my changes on the transforms branch so you can play with
> it -- I'm holding off on changing the trunk due to the pending release.
> But if everyone agrees on the way to expose this, it would be nice to
> merge this over to trunk before the release.
Am I right in assuming that the only thing we lose in this approach is
faceting (which Eric hates but others may care about)? Since it is
orders of magnitudes faster, we could have a pcolor_faceted which
pcolor calls the old function if shading='faceted'. Of course the two
functions would return different types (image vs patch collection)
which is potentially a bit confusing.... We could play with adding
faceting to images....
JDH

[To summarize an off-list conversation -- Eric and I had been discussing 
ways to speed up pcolor plots. After some improvements, quadmeshes are 
still about a factor of 2 slower on the branch than on the trunk. His 
use case often involves the simpler problem of rectilinear meshes, which 
can be handled by NonUniformImage, which should be much faster in all 
cases.]
Eric Firing wrote:
> you might want 
> to look at the long-neglected but promising pcolor method in the 
> _image.cpp, used by the NonUniformImage class in image.py.
There is an example on using NonUniformImage in pcolor_nonuniform.py 
that seems to work -- so this code isn't too neglected ;)
> I suspect that the axes pcolor method should actually be using this if 
> the grid is rectilinear and using quadmesh otherwise.
Implementation wise (just to get something working), it was easier to 
extend imshow to take two 1D-arrays X and Y which define a non-uniform 
grid for the image. (My changes merely give NonUniformImage a pyplot 
API, so the user doesn't have to do as much work as in the example.) 
But if we think this functionality belongs with pcolor, it can be 
exposed that way instead. However, there should be some way to let 
pcolor know that the mesh is rectilinear. (It would otherwise be 
wasteful computation just to determine that and proceed accordingly).
As expected, there are significant performance benefits:
Branch:
	nonuniformimage:
		init: 0.27
		fps: 21.37
	pcolormesh:
		init: 0.42
		fps: 2.61
Trunk:
	nonuniformimage:
		init: 0.25
		fps: 22.52	
	pcolormesh:
		init: 0.28
		fps: 6.64
I've committed my changes on the transforms branch so you can play with 
it -- I'm holding off on changing the trunk due to the pending release. 
But if everyone agrees on the way to expose this, it would be nice to 
merge this over to trunk before the release.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Christopher Barker wrote:
>> Michael Droettboom wrote:
>>> Wx supports polycurves in its new wxGraphicsContext API (but not the 
>>> wxDC API that mpl uses now). This means a fairly complete rewrite of 
>>> the wx backend,
>> not necessarily. You can create a GraphicsContext from a wx.DC, you may 
>> be able to just add that step for drawing polycurves.
>>
>>> since you 
>>> can no longer draw to an in-memory buffer, but only a true wxClientDC). 
>> you can create a GraphicsContext from a wxMemeoryDC, so yes, you can 
>> draw to a buffer.
> 
> I'm having trouble just getting a wxPython to compile with 
> wxGraphicsContext support (perhaps another argument against using it...)
> 
> I was basing this determination on the wx documentation which clearly 
> states one can only create a wxGraphicsContext from a wxWindowDC. 
> wxMemoryDC inherits from wxDC, not wxWindowDC. I'd be certainly happy to 
> find out that the documentation is incorrect on this point, as it would 
> certainly make the implementation easier.
I did finally get this to work -- thanks for the tip that you can use a 
wxGraphicsContext on a wxMemoryDC.
>> I haev no idea what the impact on performance would be, but in general, 
>> GraphicsContext is slower than DC.
> 
> Particularly, if it works as it appears to by rendering to a Cairo 
> buffer first.
It's really bad, actually. It's entirely possible that I'm doing things 
suboptimally, of course. If someone with more wx.GraphicsContext 
experience were to look at backend_wx.py on the branch, I'd appreciate it.
I particularly wonder if drawing directly to a wx.Window would perform 
better over the network than to a wx.MemoryDC and then blitting that to 
the window (as both trunk and branch do now). Clipping rectangles have 
a major impact also. I did optimize the code so that the clipping state 
changes as infrequently as possible (rather than with each drawing 
operation), but it still has a huge impact. I suspect that 
wx.GraphicsContext treats all clips as clipping paths, rather than the 
more efficient clipping rectangles when it can.
These benchmarks are on the branch on a RHEL4 box.
Local:
WxAgg: 27.5 fps
Wx: 1.8 fps
Wx:	16.8 fps (without clipping)
Network (X11 with compression):
WxAgg:	 2.0 fps
Wx:	 1.7 fps
Wx:	 2.0 fps (without clipping)
Windows and Mac may perform quite differently, given that they use 
completely different rendering code.
Unless some "trick" can be found to make this better, it's hard to 
recommend Wx over WxAgg on the branch.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

OK, the fix in the latest SVN does seem to work.
Andrew
On 9 Nov 2007, at 13:24, Michael Droettboom wrote:
> There is a (probable) fix for this in SVN r4179. I can't get to a 
> Mac to test right now -- can you please confirm that fixes your 
> problem? You may need to remove ~/.matplotlibrc/fontManager.cache 
> (just once) in case the earlier bug has messed up the cache.
>
> Andrew Jaffe wrote:
>> Andrew Jaffe wrote:
>>> Hi-
>>>
>>> I've got two Intel OSX machines running matplotlib.
>>>
>>> I recently upgraded one of them to the latest MPL svn. On one 
>>> machine, I had some pytz-related problems which I resolved, and I 
>>> was able to use it more or less fine. However, when the very 
>>> first time I started it, there was a huge pause which I 
>>> eventually realized had something to do with the font cache, but 
>>> it seems OK since then (but perhaps there should be a warning 
>>> message when the cache is being built?)
>
> Perhaps you have a lot of fonts on your system. I see your point 
> about the warning message, but sometimes when the user is presented 
> with too much information, they just train themselves to ignore all 
> of it...
>
>>> On the other machine, however, I got the traceback below, which I 
>>> eventually traced to the call OSXInstalledFonts() in 
>>> findSystemFonts(). Unfortunately, OSXInstalledFonts() is really
>>> OSXInstalledFonts(directory=None, fontext=None)
>>> which then calls
>>> fontext = get_fontext_synonyms(fontext)
>>> which fails with fontext=None.
>>>
>>> I was actually able to fix this by copying the .matplottlib 
>>> directory
>>> from the working machine, but it's still clearly a bug!
>> Actually, sorry, this *doesn't* fix the problem on machine number 
>> 2 (it just lets ipython -pylab start without crashing, but 
>> actually calling, e.g., plot(x,y) still fails for the same reason).
>>> Yours,
>>>
>>> Andrew
>>>
>>>
>>>
>>> Traceback (most recent call last):
>>> File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
>>> load_entry_point('ipython==0.8.1', 'console_scripts', 
>>> 'ipython')()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/ipapi.py", line 356, in 
>>> launch_new_instance
>>> ses = make_session(user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/ipapi.py", line 405, in make_session
>>> return IPython.Shell.start(user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 1111, in start
>>> return shell(user_ns = user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 1008, in __init__
>>> shell_class=MatplotlibShell)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 74, in __init__
>>> debug=debug,shell_class=shell_class)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", line 95, in 
>>> make_IPython
>>> embedded=embedded,**kw)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 562, in __init__
>>> user_ns,b2 = self._matplotlib_config(name,user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 503, in 
>>> _matplotlib_config
>>> import matplotlib.pylab as pylab
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> pylab.py", line 208, in <module>
>>> from matplotlib import mpl # pulls in most modules
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> mpl.py", line 3, in <module>
>>> from matplotlib import axis
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> axis.py", line 20, in <module>
>>> from font_manager import FontProperties
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 1129, in <module>
>>> _rebuild()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 1120, in _rebuild
>>> fontManager = FontManager()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 884, in __init__
>>> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 254, in findSystemFonts
>>> for f in OSXInstalledFonts():
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 180, in OSXInstalledFonts
>>> fontext = get_fontext_synonyms(fontext)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 100, in get_fontext_synonyms
>>> 'afm': ('afm',)}[fontext]
>>> KeyError: None
>>> gog:~% mv .matplotlib tmp.matplotlib; scp
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a 
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a 
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> 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
______________________________________________________________________
Andrew Jaffe a....@im...
Astrophysics Group +44 207 594-7526
Blackett Laboratory, Room 1013 FAX 7541
Imperial College, Prince Consort Road
London SW7 2AZ ENGLAND http://astro.imperial.ac.uk/~jaffe

There is a (probable) fix for this in SVN r4179. I can't get to a Mac 
to test right now -- can you please confirm that fixes your problem? 
You may need to remove ~/.matplotlibrc/fontManager.cache (just once) in 
case the earlier bug has messed up the cache.
Andrew Jaffe wrote:
> Andrew Jaffe wrote:
>> Hi-
>>
>> I've got two Intel OSX machines running matplotlib.
>>
>> I recently upgraded one of them to the latest MPL svn. On one machine, 
>> I had some pytz-related problems which I resolved, and I was able to use 
>> it more or less fine. However, when the very first time I started it, 
>> there was a huge pause which I eventually realized had something to do 
>> with the font cache, but it seems OK since then (but perhaps there 
>> should be a warning message when the cache is being built?)
Perhaps you have a lot of fonts on your system. I see your point about 
the warning message, but sometimes when the user is presented with too 
much information, they just train themselves to ignore all of it...
>> On the other machine, however, I got the traceback below, which I 
>> eventually traced to the call OSXInstalledFonts() in findSystemFonts(). 
>> Unfortunately, OSXInstalledFonts() is really
>> OSXInstalledFonts(directory=None, fontext=None)
>> which then calls
>> fontext = get_fontext_synonyms(fontext)
>> which fails with fontext=None.
>>
>> I was actually able to fix this by copying the .matplottlib directory
>> from the working machine, but it's still clearly a bug!
> 
> Actually, sorry, this *doesn't* fix the problem on machine number 2 (it 
> just lets ipython -pylab start without crashing, but actually calling, 
> e.g., plot(x,y) still fails for the same reason).
> 
> 
>> Yours,
>>
>> Andrew
>>
>>
>>
>> Traceback (most recent call last):
>> File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
>> load_entry_point('ipython==0.8.1', 'console_scripts', 'ipython')()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
>> line 356, in launch_new_instance
>> ses = make_session(user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
>> line 405, in make_session
>> return IPython.Shell.start(user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 1111, in start
>> return shell(user_ns = user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 1008, in __init__
>> shell_class=MatplotlibShell)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 74, in __init__
>> debug=debug,shell_class=shell_class)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", 
>> line 95, in make_IPython
>> embedded=embedded,**kw)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 562, in __init__
>> user_ns,b2 = self._matplotlib_config(name,user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 503, in _matplotlib_config
>> import matplotlib.pylab as pylab
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", 
>> line 208, in <module>
>> from matplotlib import mpl # pulls in most modules
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", 
>> line 3, in <module>
>> from matplotlib import axis
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", 
>> line 20, in <module>
>> from font_manager import FontProperties
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 1129, in <module>
>> _rebuild()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 1120, in _rebuild
>> fontManager = FontManager()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 884, in __init__
>> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 254, in findSystemFonts
>> for f in OSXInstalledFonts():
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 180, in OSXInstalledFonts
>> fontext = get_fontext_synonyms(fontext)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 100, in get_fontext_synonyms
>> 'afm': ('afm',)}[fontext]
>> KeyError: None
>> gog:~% mv .matplotlib tmp.matplotlib; scp
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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

I think that's something I recently introduced, and should probably be simple to fix. I'll have a look when I get into the office this morning.
Cheers,
Mike

Andrew Jaffe wrote:
> Hi-
> 
> I've got two Intel OSX machines running matplotlib.
> 
> I recently upgraded one of them to the latest MPL svn. On one machine, 
> I had some pytz-related problems which I resolved, and I was able to use 
> it more or less fine. However, when the very first time I started it, 
> there was a huge pause which I eventually realized had something to do 
> with the font cache, but it seems OK since then (but perhaps there 
> should be a warning message when the cache is being built?)
> 
> On the other machine, however, I got the traceback below, which I 
> eventually traced to the call OSXInstalledFonts() in findSystemFonts(). 
> Unfortunately, OSXInstalledFonts() is really
> OSXInstalledFonts(directory=None, fontext=None)
> which then calls
> fontext = get_fontext_synonyms(fontext)
> which fails with fontext=None.
> 
> I was actually able to fix this by copying the .matplottlib directory
> from the working machine, but it's still clearly a bug!
Actually, sorry, this *doesn't* fix the problem on machine number 2 (it 
just lets ipython -pylab start without crashing, but actually calling, 
e.g., plot(x,y) still fails for the same reason).
> 
> Yours,
> 
> Andrew
> 
> 
> 
> Traceback (most recent call last):
> File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
> load_entry_point('ipython==0.8.1', 'console_scripts', 'ipython')()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
> line 356, in launch_new_instance
> ses = make_session(user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
> line 405, in make_session
> return IPython.Shell.start(user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 1111, in start
> return shell(user_ns = user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 1008, in __init__
> shell_class=MatplotlibShell)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 74, in __init__
> debug=debug,shell_class=shell_class)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", 
> line 95, in make_IPython
> embedded=embedded,**kw)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 562, in __init__
> user_ns,b2 = self._matplotlib_config(name,user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 503, in _matplotlib_config
> import matplotlib.pylab as pylab
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", 
> line 208, in <module>
> from matplotlib import mpl # pulls in most modules
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", 
> line 3, in <module>
> from matplotlib import axis
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", 
> line 20, in <module>
> from font_manager import FontProperties
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 1129, in <module>
> _rebuild()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 1120, in _rebuild
> fontManager = FontManager()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 884, in __init__
> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 254, in findSystemFonts
> for f in OSXInstalledFonts():
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 180, in OSXInstalledFonts
> fontext = get_fontext_synonyms(fontext)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 100, in get_fontext_synonyms
> 'afm': ('afm',)}[fontext]
> KeyError: None
> gog:~% mv .matplotlib tmp.matplotlib; scp
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/

Hi-
I've got two Intel OSX machines running matplotlib.
I recently upgraded one of them to the latest MPL svn. On one machine, 
I had some pytz-related problems which I resolved, and I was able to use 
it more or less fine. However, when the very first time I started it, 
there was a huge pause which I eventually realized had something to do 
with the font cache, but it seems OK since then (but perhaps there 
should be a warning message when the cache is being built?)
On the other machine, however, I got the traceback below, which I 
eventually traced to the call OSXInstalledFonts() in findSystemFonts(). 
Unfortunately, OSXInstalledFonts() is really
 OSXInstalledFonts(directory=None, fontext=None)
which then calls
 fontext = get_fontext_synonyms(fontext)
which fails with fontext=None.
I was actually able to fix this by copying the .matplottlib directory
from the working machine, but it's still clearly a bug!
Yours,
Andrew
Traceback (most recent call last):
 File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
 load_entry_point('ipython==0.8.1', 'console_scripts', 'ipython')()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
line 356, in launch_new_instance
 ses = make_session(user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
line 405, in make_session
 return IPython.Shell.start(user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 1111, in start
 return shell(user_ns = user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 1008, in __init__
 shell_class=MatplotlibShell)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 74, in __init__
 debug=debug,shell_class=shell_class)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", 
line 95, in make_IPython
 embedded=embedded,**kw)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 562, in __init__
 user_ns,b2 = self._matplotlib_config(name,user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 503, in _matplotlib_config
 import matplotlib.pylab as pylab
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", 
line 208, in <module>
 from matplotlib import mpl # pulls in most modules
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", 
line 3, in <module>
 from matplotlib import axis
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", 
line 20, in <module>
 from font_manager import FontProperties
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 1129, in <module>
 _rebuild()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 1120, in _rebuild
 fontManager = FontManager()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 884, in __init__
 self.ttffiles = findSystemFonts(paths) + findSystemFonts()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 254, in findSystemFonts
 for f in OSXInstalledFonts():
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 180, in OSXInstalledFonts
 fontext = get_fontext_synonyms(fontext)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 100, in get_fontext_synonyms
 'afm': ('afm',)}[fontext]
KeyError: None
gog:~% mv .matplotlib tmp.matplotlib; scp

On Nov 8, 2007, at 10:23 AM, Michael Droettboom wrote:
>
> So, we need to look at the pros/cons of continuing to support these
> legacy APIs going forward.
I've got some more benchmarks for the WX and WXAgg backends in 
trunk. It looks like using ssh with compression or the NX remote 
desktop both substantially improve performance. I don't know why 
WXAgg consistently outperforms WX for me, but my guess is that the 
difference involves Apple's X server.
X11 Remote
	WX: 0.96 fps
	WXAgg: 1.93 fps
X11 Remote w/compression
	WX: 3.93 fps
	WXAgg: 6.43 fps
NX
	WX: 7.39 fps
	WXAgg: 10.83 fps
Local
	WX: 11.91 fps
	WXAgg: 19.16 fps
Ken

Christopher Barker wrote:
> Michael Droettboom wrote:
>> Wx supports polycurves in its new wxGraphicsContext API (but not the 
>> wxDC API that mpl uses now). This means a fairly complete rewrite of 
>> the wx backend,
> 
> not necessarily. You can create a GraphicsContext from a wx.DC, you may 
> be able to just add that step for drawing polycurves.
>
>> since you 
>> can no longer draw to an in-memory buffer, but only a true wxClientDC). 
> 
> you can create a GraphicsContext from a wxMemeoryDC, so yes, you can 
> draw to a buffer.
I'm having trouble just getting a wxPython to compile with 
wxGraphicsContext support (perhaps another argument against using it...)
I was basing this determination on the wx documentation which clearly 
states one can only create a wxGraphicsContext from a wxWindowDC. 
wxMemoryDC inherits from wxDC, not wxWindowDC. I'd be certainly happy to 
find out that the documentation is incorrect on this point, as it would 
certainly make the implementation easier.
> I haev no idea what the impact on performance would be, but in general, 
> GraphicsContext is slower than DC.
Particularly, if it works as it appears to by rendering to a Cairo 
buffer first.
>> So, we need to look at the pros/cons of continuing to support these 
>> legacy APIs going forward.
> 
> yup. I know I never need a non-agg wx, but then I can see why folks 
> running remote X severs would want it.
> 
> I wonder if there is another way to speed that up with Agg -- can you 
> compress the bitmap data to pass it to the Xserver? is that happening 
> already?
You can compress the ssh connection over which X11 tunnels with the -C
commandline flag. But whether that makes things faster or slower 
depends on the compressability of the data itself, and the relative 
speeds of the processor vs. network link, of course.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 8, 2007 7:10 AM, Darren Dale <dar...@co...> wrote:
> Fernando, do you have a record of the changes you guys made at SciPy-2007?
No, we just went through the codebase by hand and quickly removed
anything that looked like it would do namespace packages. Once that
was out of the way, the traits init was actually *shorter* than the
non-traits one, since traits property-like checks are dispatched in a
tight, highly optimized C core (ctraits.c) instead of via pure python.
Sorry not to have that benchmark code available, at this point I think
I'd have to redo it by hand.
Cheers,
f

On Nov 8, 2007, at 12:17 PM, Christopher Barker wrote:
>
> I wonder if there is another way to speed that up with Agg -- can you
> compress the bitmap data to pass it to the Xserver? is that happening
> already?
I'm not aware of any obvious method for enabling compression in 
remote X11 connections. Using the NX remote desktop system might be 
faster:
	http://www.nomachine.com
Ken

Michael Droettboom wrote:
> Gael Varoquaux wrote:
>> On Thu, Nov 08, 2007 at 11:23:54AM -0500, Michael Droettboom wrote:
>>> So, we need to look at the pros/cons of continuing to support these
>>> legacy APIs going forward.
>> IMHO a gtk and a wx back end are very important for embedding MPL in
>> applications. I am sure you have a replacement proposition, but I fail to
>> see in your list of back-end what it would be.
> 
> I'm talking specifically about the gdk and wx drawing backends, not the 
> GUI backends. Gtk and Wx applications that embed MPL can still use Agg 
> (or Cairo with Gtk) for rendering.
Can Cairo handle the remote-X use case?
Eric

Michael Droettboom wrote:
> Wx supports polycurves in its new wxGraphicsContext API (but not the 
> wxDC API that mpl uses now). This means a fairly complete rewrite of 
> the wx backend,
not necessarily. You can create a GraphicsContext from a wx.DC, you may 
be able to just add that step for drawing polycurves.
> since you 
> can no longer draw to an in-memory buffer, but only a true wxClientDC). 
you can create a GraphicsContext from a wxMemeoryDC, so yes, you can 
draw to a buffer.
I haev no idea what the impact on performance would be, but in general, 
GraphicsContext is slower than DC.
> So, we need to look at the pros/cons of continuing to support these 
> legacy APIs going forward.
yup. I know I never need a non-agg wx, but then I can see why folks 
running remote X severs would want it.
I wonder if there is another way to speed that up with Agg -- can you 
compress the bitmap data to pass it to the Xserver? is that happening 
already?
-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...

Gael Varoquaux wrote:
> On Thu, Nov 08, 2007 at 11:23:54AM -0500, Michael Droettboom wrote:
>> So, we need to look at the pros/cons of continuing to support these
>> legacy APIs going forward.
> 
> IMHO a gtk and a wx back end are very important for embedding MPL in
> applications. I am sure you have a replacement proposition, but I fail to
> see in your list of back-end what it would be.
I'm talking specifically about the gdk and wx drawing backends, not the 
GUI backends. Gtk and Wx applications that embed MPL can still use Agg 
(or Cairo with Gtk) for rendering.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Nov 08, 2007 at 11:23:54AM -0500, Michael Droettboom wrote:
> So, we need to look at the pros/cons of continuing to support these
> legacy APIs going forward.
IMHO a gtk and a wx back end are very important for embedding MPL in
applications. I am sure you have a replacement proposition, but I fail to
see in your list of back-end what it would be.
Cheers,
Gaël

The following drawing backends are functional on the transforms branch:
	Agg
	Ps
	Pdf *
	Svg
	Cairo *
* These could still use some optimizations to draw_markers and/or 
draw_path_collection.
Now onto the "problem" ones. I had asked on the mailing list a while 
back about the current usefulness of the Gdk and Wx backends, and the 
one advantage cited was that they are faster when running in a remote X 
session (a valid point for some uses). I can confirm that this is the 
case -- for a completely non-controlled experiment, I ran a remote X11 
session over our network here. I get (on simple_plot_fps.py):
Gtk: 38.44 fps
GtkAgg: 1.87 fps
Wx: 19.37 fps
WxAgg: 1.83 fps
Running locally, I get:
Gtk: 49.39 fps
GtkAgg: 27.15 fps
Wx: 19.40 fps
WxAgg: 26.04 fps
Interestingly, WxAgg is faster than Wx when running locally.
What makes updating these backends on the branch difficult? The 
fundamental drawing operation on the branch is compound polycurves (i.e. 
one or more separate polylines with possible bezier curve segments).
Gdk doesn't support polycurves natively. We could convert our 
polycurves to polygons (by approximating the bezier curves) on the fly 
and send that. That shouldn't be a major slow down in the case where 
there aren't in fact any curves, but it would mean writing some 
extension code etc.
Wx supports polycurves in its new wxGraphicsContext API (but not the 
wxDC API that mpl uses now). This means a fairly complete rewrite of 
the wx backend, that would likely affect embedders as well (since you 
can no longer draw to an in-memory buffer, but only a true wxClientDC). 
 wxGraphicsContext is built on top of GDI+, Quartz or Cairo depending 
on platform -- therefore it's not a given that it will perform well over 
remote X-Windows, either.
So, we need to look at the pros/cons of continuing to support these 
legacy APIs going forward.
Lastly, what is the status of the EMF backend? Is anyone relying on it 
and/or willing to look into updating it?
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thursday 08 November 2007 03:16:14 am Eric Firing wrote:
> Darren Dale wrote:
> > Building does not seem to be a problem, just do the usual python setup.=
py
> > build, etc. I ran backend_driver on my not-so-speedy home computer:
>
> Darren,
>
> Well done! I blew away other versions of traits, updated mpl, built and
> installed, and traits appeared. No pain.
>
> The not quite as good news is that on my Lenovo T60 laptop, the Template
> takes 0.57 minutes with traited config versus 0.45 with old config. Not
> a huge difference, and roughly consistent with your timing, but still a
> penalty. I also see about 20% in simple_plot using Agg. It's probably
> tolerable. (The comparison was made by switching only the NEWCONFIG
> variable in __init__.py.)
Yes, these results are not consistent with what Fernando reported after=20
working with Dave Peterson:
# Using traits
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.844u 0.212s 0:02.13 96.2% =A0 =A0 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.840u 0.216s 0:02.58 79.4% =A0 =A0 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.836u 0.196s 0:02.12 95.2% =A0 =A0 0+0k 0+0io 0pf+0w
# NOT Using traits
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.200u 0.280s 0:02.67 92.8% =A0 =A0 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.248u 0.220s 0:02.74 89.7% =A0 =A0 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.216u 0.244s 0:02.72 90.0% =A0 =A0 0+0k 0+0io 0pf+0w
=46ernando, do you have a record of the changes you guys made at SciPy-2007?
> > with traited config:
> >
> > Backend Agg took 2.77 minutes to complete
> > template ratio 1.748, template residual 1.187
> > Backend PS took 2.64 minutes to complete
> > template ratio 1.666, template residual 1.055
> > Backend Template took 1.59 minutes to complete
> > template ratio 1.000, template residual 0.000
> > Backend PDF took 3.35 minutes to complete
> > template ratio 2.112, template residual 1.764
> > Backend SVG took 2.90 minutes to complete
> > template ratio 1.826, template residual 1.309
> >
> >
> > and without:
> >
> > Backend Agg took 2.59 minutes to complete
> > template ratio 1.898, template residual 1.226
> > Backend PS took 2.29 minutes to complete
> > template ratio 1.675, template residual 0.921
> > Backend Template took 1.36 minutes to complete
> > template ratio 1.000, template residual 0.000
> > Backend PDF took 2.92 minutes to complete
> > template ratio 2.139, template residual 1.555
> > Backend SVG took 2.91 minutes to complete
> > template ratio 2.129, template residual 1.541

Darren Dale wrote:
> Building does not seem to be a problem, just do the usual python setup.py 
> build, etc. I ran backend_driver on my not-so-speedy home computer:
Darren,
Well done! I blew away other versions of traits, updated mpl, built and 
installed, and traits appeared. No pain.
The not quite as good news is that on my Lenovo T60 laptop, the Template 
takes 0.57 minutes with traited config versus 0.45 with old config. Not 
a huge difference, and roughly consistent with your timing, but still a 
penalty. I also see about 20% in simple_plot using Agg. It's probably 
tolerable. (The comparison was made by switching only the NEWCONFIG 
variable in __init__.py.)
Eric
> 
> with traited config:
> 
> Backend Agg took 2.77 minutes to complete
> template ratio 1.748, template residual 1.187
> Backend PS took 2.64 minutes to complete
> template ratio 1.666, template residual 1.055
> Backend Template took 1.59 minutes to complete
> template ratio 1.000, template residual 0.000
> Backend PDF took 3.35 minutes to complete
> template ratio 2.112, template residual 1.764
> Backend SVG took 2.90 minutes to complete
> template ratio 1.826, template residual 1.309
> 
> 
> and without:
> 
> Backend Agg took 2.59 minutes to complete
> template ratio 1.898, template residual 1.226
> Backend PS took 2.29 minutes to complete
> template ratio 1.675, template residual 0.921
> Backend Template took 1.36 minutes to complete
> template ratio 1.000, template residual 0.000
> Backend PDF took 2.92 minutes to complete
> template ratio 2.139, template residual 1.555
> Backend SVG took 2.91 minutes to complete
> template ratio 2.129, template residual 1.541
> 
> 
> changes in svn-4156.
> 
> Darren

On Wednesday 07 November 2007 3:54:36 pm Darren Dale wrote:
> On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> > Darren Dale wrote:
> > > I have been working on updating the trunk to provide enthought.traits
> > > version 2.6b1. backend_driver.py is running without exceptions using
> > > the traited config package with the internal traits package.
[...]
> > 2) Does Gael's version already get around the slow initialization
> > problem? (I presume so--it was pkg-resources that was causing the
> > trouble, wasn't it?) I think this is important. Some mpl applications
> > involve running simple scripts many times, so startup time matters. I
> > would not want to see traits as an external dependency if that brought
> > with it the startup lag--apart from all the other questions associated
> > with making it an external dependency in any of its present forms.
>
> I think it does get us around the initialization problem, although I need
> to run backend_driver once I get the installation worked out to be sure.
I removed the old enthought package from lib/matplotlib, and added the 
setuptools-less 2.6b1 package to lib/. It now installs like pytz or dateutil, 
directly into site-packages and only if it is not already available. The only 
modification I made to the enthought code was in the version files, which 
return '2.6b1-mpl' instead of ''. The sys.path workaround mentioned in the 
original post is no longer necessary and has been removed.
Building does not seem to be a problem, just do the usual python setup.py 
build, etc. I ran backend_driver on my not-so-speedy home computer:
with traited config:
Backend Agg took 2.77 minutes to complete
 template ratio 1.748, template residual 1.187
Backend PS took 2.64 minutes to complete
 template ratio 1.666, template residual 1.055
Backend Template took 1.59 minutes to complete
 template ratio 1.000, template residual 0.000
Backend PDF took 3.35 minutes to complete
 template ratio 2.112, template residual 1.764
Backend SVG took 2.90 minutes to complete
 template ratio 1.826, template residual 1.309
and without:
Backend Agg took 2.59 minutes to complete
 template ratio 1.898, template residual 1.226
Backend PS took 2.29 minutes to complete
 template ratio 1.675, template residual 0.921
Backend Template took 1.36 minutes to complete
 template ratio 1.000, template residual 0.000
Backend PDF took 2.92 minutes to complete
 template ratio 2.139, template residual 1.555
Backend SVG took 2.91 minutes to complete
 template ratio 2.129, template residual 1.541
changes in svn-4156.
Darren

On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> Darren Dale wrote:
> > I have been working on updating the trunk to provide enthought.traits
> > version 2.6b1. backend_driver.py is running without exceptions using the
> > traited config package with the internal traits package.
> >
> > Issues:
> >
> > 1) there are lots of absolute package imports scattered throughout
> > traits' code. I worked around this by adding a line to
> > matplotlib/__init__.py:
> >
> > sys.path.append(os.path.split(__file__)[0])
> >
> > This lets matplotlib access enthought.traits without modifying enthoughts
> > code (anymore than Gael had already done by stripping the pkg_resources
> > imports).
> >
> > 2) When I tried updating rc_traits.py to import
> > matplotlib.enthought.traits instead of enthought.traits (which isnt on
> > the PYTHONPATH), I discovered a problem:
> >
> > enthought.traits.trait_errors.TraitError: The 'parents_items' trait of a
> > ViewElements instance must be a TraitListEvent, but a value of
> > <matplotlib.enthought.traits.trait_handlers.TraitListEvent object at
> > 0x850454c> was specified.
> >
> > So traits would be a behind-the-scenes package, for internal mpl use
> > only.
>
> Regarding (1) and (2), and asking out of ignorance:
>
> 1) If an internal version of traits is to be used, how hard would it be
> to patch it in such a way that it *could* be used externally?
I think this would be too significant an undertaking to seriously consider. 
The easier part is replacing all the "from enthought" imports in the library 
to "from matplotlib.enthought", and they are scattered throughout the code. 
The harder part seems to be the error messages due to traits expecting 
enthought.traits objects, not matplotlib.enthought.traits objects.
Johns suggestion that we try to deal with traits the same way we do pytz and 
datetime should solve this, with a caveat:
> 2) Does Gael's version already get around the slow initialization
> problem? (I presume so--it was pkg-resources that was causing the
> trouble, wasn't it?) I think this is important. Some mpl applications
> involve running simple scripts many times, so startup time matters. I
> would not want to see traits as an external dependency if that brought
> with it the startup lag--apart from all the other questions associated
> with making it an external dependency in any of its present forms.
I think it does get us around the initialization problem, although I need to 
run backend_driver once I get the installation worked out to be sure. 
However, if the user already has traits installed on their system, it will 
not be stripped of pkg_imports, so the work-around would only apply to the 
mpl-shipped version of traits.
> > 3) We can not include traits-3 without either adding setuptools as an
> > external dependency (which is already true for python-2.3 users) or
> > monkey-patching distutils. traits-3 includes some pyrex code, which
> > standard distutils does not recognize.
>
> Is it a viable alternative to add pyrex as an external dependency?
> Pyrex.Distutils makes it easy to use pyrex modules via otherwise
> standard setup.py scripts. And pyrex itself is pure python, very easy
> to install.
I usually look to you and John for answers to questions like these. I think I 
tried this yesterday, and ran into a problem. You have to import build_ext 
from Pyrex.Distutils, and then pass "cmdclass = {'build_ext': build_ext}" to 
setup(). The build failed, maybe because build_ext was being applied to 
non-pyrex extension code, or maybe because I didn't know what I was doing.
> Part of my motivation in bringing this up is that I have found pyrex
> extremely useful for quick speedups and for interfacing to larger chunks
> of C code. (And I have a strong personal bias towards C and pyrex for
> extension code in preference to C++ and any of the mechanisms used to
> provide bindings for C++ code. I find the former vastly more readable,
> understandable, and hence maintainable.)
Would I be able to understand it? :)
> Pyrex (actually its variant, 
> cython) is already essential to basemap, and I am hoping for increasing
> basemap integration, as well as judicious use of extension code to make
> the transforms branch lightening-fast.