[matplotlib-devel] OSX Font cache problem
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
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 , 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
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
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
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
_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/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX Font cache problem
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
> 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 , 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
> 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
> 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
> 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
> _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
Re: [matplotlib-devel] OSX Font cache problem
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX Font cache problem
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
>> 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 , 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
>> 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
>> 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
>> 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
>> _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
Re: [matplotlib-devel] OSX Font cache problem
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
>>> 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 , 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
>>> 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
>>> 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
>>> 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
>>> _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 OSXInstalle
Re: [matplotlib-devel] Backends status on transforms branch
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
[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 import numpy as npy from numpy.random import rand import matplotlib from matplotlib.pyplot import pcolor, pcolormesh, savefig, show, ion, axis, draw, axes, imshow import time, sys ion() t = time.clock() X = npy.arange(100) X = X * X Y = npy.arange(1000) Y = Y * Y imshow(rand(1000,100), X, Y) print "init: ", time.clock() - t frames = 25.0 t = time.clock() for i in xrange(int(frames)): part = (1.0 - (i / frames) / 2.0) axes().set_ylim((0.0, 100.0 * part)) draw() print "fps:", frames / (time.clock() - t) show() import numpy as npy from numpy.random import rand import matplotlib from matplotlib.pyplot import pcolor, pcolormesh, savefig, show, ion, axis, draw, axes, imshow import time, sys ion() t = time.clock() X = npy.arange(100) X = X * X Y = npy.arange(1000) Y = Y * Y pcolormesh(X, Y, rand(1000,100)) print "init: ", time.clock() - t frames = 25.0 t = time.clock() for i in xrange(int(frames)): part = (1.0 - (i / frames) / 2.0) axes().set_ylim((0.0, 100.0 * part)) draw() print "fps:", frames / (time.clock() - t) - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
John Hunter wrote: > On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
John Hunter wrote: > On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
Eric Firing wrote: > 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. Hey, no rush. I understand not everyone has the luxury of hacking on matplotlib full time. > (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.) Seems reasonable. > (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.) Ah, yes. That whole "purity" thing. Cheers, Mike > Michael Droettboom wrote: >> John Hunter wrote: >>> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote: > Eric Firing wrote: > > 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. > > Hey, no rush. I understand not everyone has the luxury of hacking on > matplotlib full time. Do you get to hack mpl full-time? I'm jealous. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
Darren Dale wrote: > On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote: >> Eric Firing wrote: >>> 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. >> Hey, no rush. I understand not everyone has the luxury of hacking on >> matplotlib full time. > > Do you get to hack mpl full-time? I'm jealous. For the time being. And, yeah, I consider myself pretty fortunate. But I'm sure those days are numbered -- there's a lot of other interesting stuff needing to get done here... ;) Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
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 <[EMAIL PROTECTED]> 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 > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
Michael, Have you looked at the speed of zooming in and out with pcolormesh? On Nov 9, 2007 3:33 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Darren Dale wrote: > > On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote: > >> Eric Firing wrote: > >>> 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. > >> Hey, no rush. I understand not everyone has the luxury of hacking on > >> matplotlib full time. > > > > Do you get to hack mpl full-time? I'm jealous. > > For the time being. And, yeah, I consider myself pretty fortunate. But > I'm sure those days are numbered -- there's a lot of other interesting > stuff needing to get done here... ;) > > Cheers, > Mike > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > - > > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
Sorry, I didn't explain the benchmark (which was in an off-list e-mail to Eric.) The "fps" value in these benchmarks is the frames-per-second you get when updating the range of the axes (approximately what to expect from an interactive pan/zoom operation). The "init" time is the time it takes to compute the mesh in the first place and set up the initial plotting state. So, obviously, if you have a rectilinear mesh, you're much better off using NonUniformImage rather than the more general mesh. [Same results as before, copied for your convenience.] 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 Cheers, Mike william ratcliff wrote: > Michael, > > Have you looked at the speed of zooming in and out with pcolormesh? > > On Nov 9, 2007 3:33 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> Darren Dale wrote: >>> On Friday 09 November 2007 03:26:12 pm Michael Droettboom wrote: Eric Firing wrote: > 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. Hey, no rush. I understand not everyone has the luxury of hacking on matplotlib full time. >>> Do you get to hack mpl full-time? I'm jealous. >> For the time being. And, yeah, I consider myself pretty fortunate. But >> I'm sure those days are numbered -- there's a lot of other interesting >> stuff needing to get done here... ;) >> >> Cheers, >> Mike >> >> -- >> Michael Droettboom >> Science Software Branch >> Operations and Engineering Division >> Space Telescope Science Institute >> Operated by AURA for NASA >> >> - >> >> 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 >> Matplotlib-devel@lists.sourceforge.net >> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
On Fri, Nov 09, 2007 at 01:39:10PM -0600, John Hunter wrote: > On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] patch: "configure subplots" slider precision
Hello, I was using the "configure subplots" dialog a lot recently to precisely resize my plots, and I noticed that often when I changed a slider only slightly (say by 1 pixel), the numeric value displayed next to the slider wouldn't change, because its precision was too low. So, I modified the code to display 3 decimal places instead of just 2. Now, every change to the slider always causes a visible change in the displayed subplot param value. This makes it easy to precisely set your subplot params to be the same as other plots, using the gui. I've attached the short patch. I've only tested this in wxagg under win32. It's possible that on another platform there might be less space to display the extra digit, and it might get cut off, but I think that's unlikely. Cheers, Martin Index: lib/matplotlib/widgets.py === --- lib/matplotlib/widgets.py (revision 4202) +++ lib/matplotlib/widgets.py (working copy) @@ -169,7 +169,7 @@ Call on_changed to connect to the slider event """ -def __init__(self, ax, label, valmin, valmax, valinit=0.5, valfmt='%1.2f', +def __init__(self, ax, label, valmin, valmax, valinit=0.5, valfmt='%1.3f', closedmin=True, closedmax=True, slidermin=None, slidermax=None, dragging=True): """ - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
