matplotlib-devel Mailing List for matplotlib (Page 20)

Michael Droettboom wrote:
> Interesting...
> 
> When you get a chance, would you mind running the attached script? This 
> is how I was finding object leaks before. It takes a single commandline 
> argument that is the number of iterations. Can you send me the outputs 
> from 1 and 2 iterations? That way we should be able to see what type of 
> object is being leaked, which is a good first step.
And here is the result of the script modified for gtk:
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1
55352 55417
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>
uncollectable list: []
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2
55352 55421
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>
uncollectable list: []
Eric

On Thursday 05 July 2007 03:46:13 pm John Hunter wrote:
> On 7/5/07, Michael Droettboom <md...@st...> wrote:
> > Do you agree that it is still an open question whether it's better to
> > spend time improving the matplotib PS backend, or to fix (if possible)
> > the issues with matplotlib's Cairo integration? It does ultimately come
> > down to a tradeoff: an additional dependency vs. extra maintenance
>
> The postscript backend as it stands is in good shape, and is full
> featured (Darren can tell you how much work he has put into supporting
> and enhancing the latex support). The last major issue with it is the
> font size issue, and with your help a solution is on the horizon. So
> it is definitely a good use of time to fix this last bit. It doesn't
> sound like your "option 2" is a ton of work, but correct me if I'm
> wrong.
It was a fair amount of work figuring out how to support latex. Jouni started 
work on a dvi parser, see dviread.py in matplotlib/lib/matplotlib, which 
could greatly simplify the gymnastics we currently use to support latex in ps 
output. If dviread were to be further developed, latex could also be used in 
conjunction with the pdf backend (Jouni's reason for starting dviread), the 
svg backend, and I guess it would work with cairo as well. But making dviread 
robust will probably take more work than options 1 or 2, so it is probably 
best to pursue one of those options for now.
> While I would love to see cairo become a full featured backend, and
> for there to be additional GUI support like tkcairo, wxcairo, etc, we
> are a lot farther from that goal than we are to getting the font sizes
> down in the existing postscript backend. And I like the fact the mpl
> is completely BSD-ish -- relying on a core component which is LGPL
> would be a step back in my book, though having it as an option would
> be great.
Why can't we all just get along?
> Do you mean mathtext or usetex? - The former is mpl's own math layout
> using the cm*.ttf files, and should work like any other text in the
> file. The latter uses tex and dvipng rasters (at least in agg), but I
> don't think it is supported in cairo. So I am not sure where these
> rasters are coming from, unless cairo is converting all text to
> rasters.
I think he is right, gtkcairo converts mathtext to rasters. usetex is not 
support in gtkcairo.
Darren

Michael Droettboom wrote:
> Interesting...
> 
> When you get a chance, would you mind running the attached script? This 
> is how I was finding object leaks before. It takes a single commandline 
> argument that is the number of iterations. Can you send me the outputs 
> from 1 and 2 iterations? That way we should be able to see what type of 
> object is being leaked, which is a good first step.
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>
uncollectable list: []
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 
could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>
uncollectable list: []
Eric

John Hunter wrote:
> On 7/5/07, Michael Droettboom <md...@st...> wrote:
>
>
>> Do you agree that it is still an open question whether it's better to
>> spend time improving the matplotib PS backend, or to fix (if possible)
>> the issues with matplotlib's Cairo integration? It does ultimately come
>> down to a tradeoff: an additional dependency vs. extra maintenance
>
> The postscript backend as it stands is in good shape, and is full
> featured (Darren can tell you how much work he has put into supporting
> and enhancing the latex support). The last major issue with it is the
> font size issue, and with your help a solution is on the horizon. So
> it is definitely a good use of time to fix this last bit. It doesn't
> sound like your "option 2" is a ton of work, but correct me if I'm
> wrong.
No, not a ton of work. And this context is helpful.
>
> While I would love to see cairo become a full featured backend, and
> for there to be additional GUI support like tkcairo, wxcairo, etc, we
> are a lot farther from that goal than we are to getting the font sizes
> down in the existing postscript backend. And I like the fact the mpl
> is completely BSD-ish -- relying on a core component which is LGPL
> would be a step back in my book, though having it as an option would
> be great.
>
> http://www.scipy.org/License_Compatibility
Agreed.
> Do you mean mathtext or usetex? - The former is mpl's own math layout
> using the cm*.ttf files, and should work like any other text in the
> file. The latter uses tex and dvipng rasters (at least in agg), but I
> don't think it is supported in cairo. So I am not sure where these
> rasters are coming from, unless cairo is converting all text to
> rasters.
mathtext_demo.py -- It originally looked like the math text was 
rasterized, but the tick labels are not. On closer inspection, it seems 
all the text is rasterized. The fonts are not rasterized when using the 
Cairo backend with unicode_demo.py. Haven't looked into that any deeper...
Cheers,
Mike

On 7/5/07, Michael Droettboom <md...@st...> wrote:
> Do you agree that it is still an open question whether it's better to
> spend time improving the matplotib PS backend, or to fix (if possible)
> the issues with matplotlib's Cairo integration? It does ultimately come
> down to a tradeoff: an additional dependency vs. extra maintenance
The postscript backend as it stands is in good shape, and is full
featured (Darren can tell you how much work he has put into supporting
and enhancing the latex support). The last major issue with it is the
font size issue, and with your help a solution is on the horizon. So
it is definitely a good use of time to fix this last bit. It doesn't
sound like your "option 2" is a ton of work, but correct me if I'm
wrong.
While I would love to see cairo become a full featured backend, and
for there to be additional GUI support like tkcairo, wxcairo, etc, we
are a lot farther from that goal than we are to getting the font sizes
down in the existing postscript backend. And I like the fact the mpl
is completely BSD-ish -- relying on a core component which is LGPL
would be a step back in my book, though having it as an option would
be great.
http://www.scipy.org/License_Compatibility
> burden. Maybe it would be a good start to enumerate the Cairo backend's
> current shortcomings.
As a start, you might try adding cairo to the list of backends in
examples/backend_driver.py and see if everything passes, and take a
look at the generated images, eg compared to those of Agg, and see if
you identify any other discrepancies. Steve Chaplin who wrote the
cairo backend can also elaborate.
> (So far I've seen some minor text bugs, and math
> rendering is raster dumps.)
Do you mean mathtext or usetex? - The former is mpl's own math layout
using the cm*.ttf files, and should work like any other text in the
file. The latter uses tex and dvipng rasters (at least in agg), but I
don't think it is supported in cairo. So I am not sure where these
rasters are coming from, unless cairo is converting all text to
rasters.
JDH

Interesting...
When you get a chance, would you mind running the attached script? This 
is how I was finding object leaks before. It takes a single commandline 
argument that is the number of iterations. Can you send me the outputs 
from 1 and 2 iterations? That way we should be able to see what type of 
object is being leaked, which is a good first step.
If that doesn't make it immediately obvious, I'll try this on my Ubuntu 
box at home and see if I can reproduce what you're seeing.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting. I don't get that, but I do get some random segfaults (I 
>> got lucky the first time I tested).
>>
>> I'm awfully surprised that wx.GetApp() would return an iterator, as 
>> you are getting, so maybe it's corruption of some sort?
>>
>> Reverting to revision 3441 on backend_wx.py does resolve this issue 
>> for me, so it is related to removing the wxapp global variable. While I 
>
> [...]
>
> Works for me now, and the result is attached. Object count is still 
> climbing.
>
> Eric
> ------------------------------------------------------------------------
>
> # columns are: iteration, OS memory (k), number of python objects
> #
> 0 18849 75791
> 10 18849 75831
> 20 18849 75871
> 30 18849 75911
> 40 18930 75951
> 50 18930 75991
> 60 19038 76031
> 70 19038 76071
> 80 19038 76111
> 90 19038 76151
> 100 19124 76191
> 110 19124 76231
> 120 19235 76271
> 130 19235 76311
> 140 19316 76351
> 150 19316 76391
> 160 19417 76431
> 170 19417 76471
> 180 19417 76511
> 190 19513 76551
> 200 19513 76591
> 210 19513 76631
> 220 19612 76671
> 230 19612 76711
> 240 19612 76751
> 250 19710 76791
> 260 19710 76831
> 270 19710 76871
> 280 19800 76911
> 290 19800 76951
> 300 19800 76991
> 310 19893 77031
> 320 19893 77071
> 330 19893 77111
> 340 19978 77151
> 350 19978 77191
> 360 20088 77231
> 370 20088 77271
> 380 20088 77311
> 390 20192 77351
> 400 20192 77391
> 410 20192 77431
> 420 20192 77471
> 430 20274 77511
> 440 20274 77551
> 450 20374 77591
> 460 20374 77631
> 470 20374 77671
> 480 20484 77711
> 490 20484 77751
> 500 20484 77791
> 510 20588 77831
> 520 20588 77871
> 530 20588 77911
> 540 20588 77951
> 550 20683 77991
> 560 20683 78031
> 570 20683 78071
> 580 20763 78111
> 590 20796 78151
> 600 20861 78191
> 610 20961 78231
> 620 20961 78271
> 630 20961 78311
> 640 21060 78351
> 650 21060 78391
> 660 21060 78431
> 670 21156 78471
> 680 21156 78511
> 690 21156 78551
> 700 21254 78591
> 710 21254 78631
> 720 21254 78671
> 730 21353 78711
> 740 21353 78751
> 750 21353 78791
> 760 21442 78831
> 770 21442 78871
> 780 21442 78911
> 790 21528 78951
> 800 21528 78991
> 810 21638 79031
> 820 21638 79071
> 830 21638 79111
> 840 21638 79151
> 850 21733 79191
> 860 21733 79231
> 870 21733 79271
> 880 21820 79311
> 890 21820 79351
> 900 21931 79391
> 910 21931 79431
> 920 21931 79471
> 930 21931 79511
> 940 22015 79551
> 950 22015 79591
> 960 22126 79631
> 970 22126 79671
> 980 22126 79711
> 990 22126 79751
> 1000 22207 79791
> 1010 22207 79831
> 1020 22298 79871
> 1030 22298 79911
> 1040 22335 79951
> 1050 22401 79991
> 1060 22503 80031
> 1070 22503 80071
> 1080 22503 80111
> 1090 22601 80151
> 1100 22601 80191
> 1110 22601 80231
> 1120 22699 80271
> 1130 22699 80311
> 1140 22699 80351
> 1150 22798 80391
> 1160 22798 80431
> 1170 22798 80471
> 1180 22897 80511
> 1190 22897 80551
> 1200 22897 80591
> 1210 22995 80631
> 1220 22995 80671
> 1230 22995 80711
> 1240 23086 80751
> 1250 23086 80791
> 1260 23086 80831
> 1270 23180 80871
> 1280 23180 80911
> 1290 23283 80951
> 1300 23283 80991
> 1310 23283 81031
> 1320 23283 81071
> 1330 23366 81111
> 1340 23366 81151
> 1350 23475 81191
> 1360 23475 81231
> 1370 23475 81271
> 1380 23475 81311
> 1390 23552 81351
> 1400 23552 81391
> 1410 23643 81431
> 1420 23643 81471
> 1430 23595 81511
> 1440 23700 81551
> 1450 23808 81591
> 1460 23808 81631
> 1470 23808 81671
> 1480 23787 81711
> 1490 23852 81751
> 1500 23951 81791
> 1510 24048 81831
> 1520 24048 81871
> 1530 24048 81911
> 1540 24146 81951
> 1550 24146 81991
> 1560 24146 82031
> 1570 24247 82071
> 1580 24247 82111
> 1590 24247 82151
> 1600 24344 82191
> 1610 24344 82231
> 1620 24344 82271
> 1630 24442 82311
> 1640 24442 82351
> 1650 24442 82391
> 1660 24542 82431
> 1670 24542 82471
> 1680 24542 82511
> 1690 24639 82551
> 1700 24639 82591
> 1710 24639 82631
> 1720 24738 82671
> 1730 24738 82711
> 1740 24738 82751
> 1750 24837 82791
> 1760 24837 82831
> 1770 24837 82871
> 1780 24935 82911
> 1790 24935 82951
> 1800 24935 82991
> 1810 25025 83031
> 1820 25025 83071
> 1830 25025 83111
> 1840 25118 83151
> 1850 25118 83191
> 1860 25104 83231
> 1870 25170 83271
> 1880 25281 83311
> 1890 25281 83351
> 1900 25281 83391
> 1910 25385 83431
> 1920 25385 83471
> 1930 25385 83511
> 1940 25362 83551
> 1950 25400 83591
> 1960 25469 83631
> 1970 25596 83671
> 1980 25596 83711
> 1990 25693 83751
> 2000 25693 83791
> # columns above are: iteration, OS memory (k), number of python objects
> #
> # uncollectable list: []
> #
> # Backend WX, toolbar toolbar2
> # wxPython version: 2.8.1.1
> # Averaging over loops 1000 to 2000
> # Memory went from 22207k to 25693k
> # Average memory consumed per loop: 3.4860k bytes
>
> 

Michael Droettboom wrote:
> Interesting. I don't get that, but I do get some random segfaults (I 
> got lucky the first time I tested).
> 
> I'm awfully surprised that wx.GetApp() would return an iterator, as you 
> are getting, so maybe it's corruption of some sort?
> 
> Reverting to revision 3441 on backend_wx.py does resolve this issue for 
> me, so it is related to removing the wxapp global variable. While I 
[...]
Works for me now, and the result is attached. Object count is still 
climbing.
Eric

John Hunter wrote:
> On 7/5/07, Michael Droettboom <md...@st...> wrote:
>
>> It may be worthwhile to look at Cairo's font subsetting code if it's
>> determined that the Python Postscript backend has other advantages. I'm
>> sure people who've been here longer than I have can better speak to
>> those pros and cons.
>
> Unfortunately, because it is LGPL, I don't think we can in good
> conscience look at the code, because doing so probably violates the
> spirit of the LGPL which says you can link with it but not reuse the
> code in a non GPL/LGPL program. Others may have a different
> interpretation, and if look but don't copy is OK under the LGPL as it
> is journalism (read and summarize with citation but don't plagiarize)
> then its fine by me but that's not my current understanding.
Agreed. I haven't looked at it the Cairo source yet, so you can still 
consider me "untainted" in that regard. My earlier comment was mainly 
out of licensing confusion. ;)
Do you agree that it is still an open question whether it's better to 
spend time improving the matplotib PS backend, or to fix (if possible) 
the issues with matplotlib's Cairo integration? It does ultimately come 
down to a tradeoff: an additional dependency vs. extra maintenance 
burden. Maybe it would be a good start to enumerate the Cairo backend's 
current shortcomings. (So far I've seen some minor text bugs, and math 
rendering is raster dumps.)
Cheers,
Mike

Interesting. I don't get that, but I do get some random segfaults (I 
got lucky the first time I tested).
I'm awfully surprised that wx.GetApp() would return an iterator, as you 
are getting, so maybe it's corruption of some sort?
Reverting to revision 3441 on backend_wx.py does resolve this issue for 
me, so it is related to removing the wxapp global variable. While I 
like the idea of removing global variables, that was problematic, since 
when the wxapp variable is dereferenced, the whole wx.App is destructed, 
(hence, I believe the segfaults). Since I didn't want to just put the 
wxapp global variable back in, I assigned it to the figure that creates 
it, therefore stick around as long as the figure does. (Is that the 
correct thing for its lifetime?) Anyway, it seems to fix memleak_gui.py 
for me. Ken and Tim will probably want to check that I didn't cause 
more mainloops to start than necessary in the process.
Also, I'm a little puzzled by this code in show() in backend_wx.py:
 wxapp = wx.GetApp()
 if wxapp is not None:
 # wxPython 2.4 has no wx.App.IsMainLoopRunning() method
 imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False)
 if imlr():
 wxapp.MainLoop()
If I'm reading this correctly, shouldn't it be "if not imlr()"? If it 
is correct, maybe it needs a comment as to why mainloops should be 
started if a mainloop is already running.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> New exception:
>
> efiring@manini:~/programs/py/mpl/tests$ python 
> ../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > 
> ~/temp/memleak_wx_0705.asc
> Traceback (most recent call last):
> File "../matplotlib_units/unit/memleak_gui.py", line 58, in <module>
> pylab.close(fig)
> File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
> line 742, in close
> _pylab_helpers.Gcf.destroy(manager.num)
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", 
> line 28, in destroy
> figManager.destroy()
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
> line 1405, in destroy
> self.frame.Destroy()
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
> line 1364, in Destroy
> wxapp.Yield()
> AttributeError: 'listiterator' object has no attribute 'Yield'
>
>
> Eric
>

On 7/5/07, Michael Droettboom <md...@st...> wrote:
> It may be worthwhile to look at Cairo's font subsetting code if it's
> determined that the Python Postscript backend has other advantages. I'm
> sure people who've been here longer than I have can better speak to
> those pros and cons.
Unfortunately, because it is LGPL, I don't think we can in good
conscience look at the code, because doing so probably violates the
spirit of the LGPL which says you can link with it but not reuse the
code in a non GPL/LGPL program. Others may have a different
interpretation, and if look but don't copy is OK under the LGPL as it
is journalism (read and summarize with citation but don't plagiarize)
then its fine by me but that's not my current understanding.
JDH

Mike,
New exception:
efiring@manini:~/programs/py/mpl/tests$ python 
../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > 
~/temp/memleak_wx_0705.asc
Traceback (most recent call last):
 File "../matplotlib_units/unit/memleak_gui.py", line 58, in <module>
 pylab.close(fig)
 File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
line 742, in close
 _pylab_helpers.Gcf.destroy(manager.num)
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", 
line 28, in destroy
 figManager.destroy()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
line 1405, in destroy
 self.frame.Destroy()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
line 1364, in Destroy
 wxapp.Yield()
AttributeError: 'listiterator' object has no attribute 'Yield'
Eric

Michael Droettboom wrote:
> Carl Worth wrote:
> 
>> You might take a look at what kind of PostScript and PDF output you
>> get from cairo right now, (since cairo has many different kinds of
>> font subsetting, (type3, type42 and others), and it's regularly being
>> tested on as many PostScript and PDF viewers as possible).
>> 
>> 
> Thanks for the tip. Indeed, using the unicode_test.py example (which 
> probably has a greater than average amount of text in it), the file 
> sizes are (with the size of the font section is parentheses):
>
> backend_ps.py: 135763 (127211)
> cairo: 49102 (39669)
>
> Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 
> 8552)
> 
Though, I should add, there is a bug in Cairo output with 
unicode_demo.py: The y-axis label reads "stream-vera/VeraSe.ttf"...
Cheers,
Mike

Carl Worth wrote:
> You might take a look at what kind of PostScript and PDF output you
> get from cairo right now, (since cairo has many different kinds of
> font subsetting, (type3, type42 and others), and it's regularly being
> tested on as many PostScript and PDF viewers as possible).
> 
Thanks for the tip. Indeed, using the unicode_test.py example (which 
probably has a greater than average amount of text in it), the file 
sizes are (with the size of the font section is parentheses):
 backend_ps.py: 135763 (127211)
 cairo: 49102 (39669)
Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 
8552)
> I don't know if there's anything special about the PostScript output
> you're currently producing that wouldn't make it acceptable to use
> cairo's PostScript output directly. But even if you just want code,
> it's inside cairo under the LGPL.
> 
It may be worthwhile to look at Cairo's font subsetting code if it's 
determined that the Python Postscript backend has other advantages. I'm 
sure people who've been here longer than I have can better speak to 
those pros and cons.
Cheers,
Mike

On 7/5/07, Carl Worth <cw...@cw...> wrote:
> You might take a look at what kind of PostScript and PDF output you
> get from cairo right now, (since cairo has many different kinds of
> font subsetting, (type3, type42 and others), and it's regularly being
> tested on as many PostScript and PDF viewers as possible).
>
> I don't know if there's anything special about the PostScript output
> you're currently producing that wouldn't make it acceptable to use
> cairo's PostScript output directly. But even if you just want code,
> it's inside cairo under the LGPL.
Hey Carl,
I looked at cairo when we first started with the postscript backend,
but in the bad old days it was just a raster dump. I understand it
has come a long way since.
mpl's postscript backend supports latex expressions in PS output,
which requires a fair amount of complex trickery in the postscript
backend, though we we could probably do it with embedded rasters in
cairo. The postscript backend is also standalone with no dependencies
other than mpl and numpy, and adding cairo to the mix might be a bit
difficult for across platforms for some users (though this appears to
have gotten a lot better too). LGPL means we cannot reuse the code.
While I like the idea of using cairo for both raster and vector
outputs in principle because it offloads a lot of work onto a large
and well supported project, it would probably take a fair amount of
work to get all of mpl's functionality into the cairo backend (I don't
know this since I have not tested the backend for some time, but does
it support, for example unicode_demo, mathtext_demo, usetex, and
image_demo ?).
JDH

Yes -- the global wxapp variable was removed (a very good thing). I 
just committed a patch to fix this crash (r3460)
Cheers,
Mike
Christopher Barker wrote:
> Eric Firing wrote:
> 
>> I just updated from svn and tried to rerun the wx test, but ran into an 
>> error:
>>
>> efiring@manini:~/programs/py/mpl/tests$ python 
>> wxapp.Yield()
>> NameError: global name 'wxapp' is not defined
>> 
>
> I think I just saw a note that Ken had committed a patch that a user had 
> provided that kept the wx back-end from re-starting an event loop if 
> there was one already running -- maybe that has something to do with 
> this bug?
>
> -Chris
>
>
>
>
> 

On 2007年7月05日 07:37:21 -1000, Eric Firing wrote:
> > 2. Convert the Truetype font to a Type 3 font (which is basically a set
> > of standard Postscript commands). There is a small C application
> > (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3
> > that looks to work quite well. Some modifications would have to be made
> > to actually subset the font and to integrate with Python etc., but it's
> > fairly straightforward code, and the licensing is amenable to including
> > it in the matplotlib source tree.
> >
> > Clearly, I'm leaning toward option #2, but thought I'd open it to the
> > crowd to see if there are any other options or opinions on the matter.
You might take a look at what kind of PostScript and PDF output you
get from cairo right now, (since cairo has many different kinds of
font subsetting, (type3, type42 and others), and it's regularly being
tested on as many PostScript and PDF viewers as possible).
I don't know if there's anything special about the PostScript output
you're currently producing that wouldn't make it acceptable to use
cairo's PostScript output directly. But even if you just want code,
it's inside cairo under the LGPL.
-Carl

Eric Firing wrote:
> I just updated from svn and tried to rerun the wx test, but ran into an 
> error:
> 
> efiring@manini:~/programs/py/mpl/tests$ python 
> wxapp.Yield()
> NameError: global name 'wxapp' is not defined
I think I just saw a note that Ken had committed a patch that a user had 
provided that kept the wx back-end from re-starting an event loop if 
there was one already running -- maybe that has something to do with 
this bug?
-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...

Will this (whichever method is chosen) work for PDF too?
Just wondering,
-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...

Michael Droettboom wrote:
> Eric Firing wrote:
>> Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of 
>> results: tkagg is best, with only slow memory growth and a constant 
>> number of python objects; qtagg grows by 2.2k per loop, with no 
>> increase in python object count; wx (which is built on gtk) consumes 
>> 3.5k per loop, with an increasing object count; gtk consumes 1.8k per 
>> loop with an increasing object count.
>>
>> All runs are on stock ubuntu feisty python 2.5.
> Thanks for these results. Unfortunately, I'm seeing different results 
> here. [dagnabbit!] None of them have an increasing object count for 
> me, which leads me to suspect there's some version difference between 
> your environment and mine that isn't being accounted for.
> 
> Gtk[Agg|Cairo] -- 1.3k per loop.
> Wx[Agg] -- 0.010k per loop
> QtAgg -- 2.3k per loop (which is in the same ballpark as your result)
> Qt4Agg -- 1.4k per loop (which seems to be in the same ballpark as 
> Darren Dale's result)
> TkAgg -- 0.29k per loop
> 
> I don't know if the size of memory per loop is directly comparable 
> between your environment and mine, but certainly the shape of the curve, 
> and whether the number of Python objects is growing is very relevant.
> 
> I made some more commits to SVN on 07/03/07 necessary for recent 
> versions of gtk+ and qt. Did you (by any chance) not get those 
> patches? It would also be interesting to know which versions of the 
> toolkits you have, as they are probably different from mine. Is it safe 
> to assume that they are all the stock Ubuntu feisty packages? In any 
> case, I have updated memleak_gui.py to display the relevant toolkit 
> versions. I've also attached a script to display the toolkit versions. 
> Its output on my machine is:
> 
> # pygtk version: (2, 10, 4), gtk version: (2, 10, 9)
> # PyQt4 version: 4.2, Qt version 40300
> # pyqt version: 3.17.2, qt version: 30303
> # wxPython version: 2.8.4.0
> # Tkinter version: $Revision: 50704 ,ドル Tk version: 8.4, Tcl version: 8.4
Here is mine--not very different from yours:
# pygtk version: (2, 10, 4), gtk version: (2, 10, 11)
# PyQt4 version: 4.1, Qt version 40202
# pyqt version: 3.17, qt version: 30307
# wxPython version: 2.8.1.1
# Tkinter version: $Revision: 50704 ,ドル Tk version: 8.4, Tcl version: 8.4
Everything is stock ubuntu feisty. wx is built on gtk.
I'm pretty sure I did the tests after your 07/03/07 commits.
I just updated from svn and tried to rerun the wx test, but ran into an 
error:
efiring@manini:~/programs/py/mpl/tests$ python 
../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > 
~/temp/memleak_wx_0705.asc
Traceback (most recent call last):
 File "../matplotlib_units/unit/memleak_gui.py", line 58, in <module>
 pylab.close(fig)
 File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
line 742, in close
 _pylab_helpers.Gcf.destroy(manager.num)
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", 
line 28, in destroy
 figManager.destroy()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
line 1403, in destroy
 self.frame.Destroy()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
line 1362, in Destroy
 wxapp.Yield()
NameError: global name 'wxapp' is not defined
Eric

Eric Firing wrote:
> Michael Droettboom wrote:
>> 1. Subset the Truetype font into another Truetype font and embed it 
>> as we do now. This could theoretically be done with fonttools/ttx. 
>> Writing out .ttf files looks to be rather complex, and there's a lot 
>> of griping about the format itself to be found on the 'net. John 
>> also mentioned that he'd prefer not to add the requirement of 
>> fonttools to the mix from past experience.
>>
>> 2. Convert the Truetype font to a Type 3 font (which is basically a 
>> set of standard Postscript commands). There is a small C application 
>> (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 
>> 3 that looks to work quite well. Some modifications would have to be 
>> made to actually subset the font and to integrate with Python etc., 
>> but it's fairly straightforward code, and the licensing is amenable 
>> to including it in the matplotlib source tree.
>>
>> Clearly, I'm leaning toward option #2, but thought I'd open it to the 
>> crowd to see if there are any other options or opinions on the matter.
>
> I'm very glad to hear that you are working on this, and option #2 
> sounds good to me. Is the potential advantage of #1 better ultimate 
> rendering quality? Or smaller file size?
Potentially on both counts. Hinting will not be converted, and since TT 
and PS have slightly different rendering models, there is the potential 
for rounding error etc. (though I don't know how real of a problem that 
is.) Also, Type 3 is an ASCII format, so if the file weren't subsetted, 
the size would certainly be larger. So a lot depends on the ratio of 
glyphs in the original font to glyphs in the figure, obviously. Of 
course, we could have an "auto" mode, where whichever is ultimately 
smaller is written out.
>
> It looks like fonttools has been untouched since 2002, correct?
I wasn't able to find anything newer either.
>
>>
>> The plan is to make the choice of the existing or new behavior be an 
>> option, with the default TBD.
>
> Is there any reason *not* to do the subsetting?
If hinting is a requirement, yes, if the PS file is to be used on a 
lo-res printer or screen. Somewhat of a side case, maybe.
Cheers,
Mike

On 7/5/07, Eric Firing <ef...@ha...> wrote:
> > The plan is to make the choice of the existing or new behavior be an
> > option, with the default TBD.
>
> Is there any reason *not* to do the subsetting?
There was some original confusion in a potential loss of quality in
truetype/type2 conversions, because of quartic vs cubic spline
approximations in the two specifications. When we were concerned that
some users may be hit by a loss-of-quality in conversion, we
considered making the conversion and subsetting optional. Michael
later clarifed that the loss (which happens only in corner cases)
would occur in the type3->truetype conversion, and not in the
truetype->type3 case we are interested in because type3 uses quartic
and truetype uses cubic. Unless there is a good reason to make it
optional, I would like to make it as simple as possible and simply do
the conversion and embedding every time. This will make support and
debugging easier.
JDH

Michael Droettboom wrote:
> [I've been discussing this off-list with John Hunter, and I thought I'd 
> summarize that conversation in case anyone else on this list has any 
> thoughts or suggestions.]
> 
> I've started working on the problem of reducing Postscript output file 
> sizes by saving out only the glyphs that are used in the figure. There 
> are (at least) two alternative approaches:
> 
> 1. Subset the Truetype font into another Truetype font and embed it as 
> we do now. This could theoretically be done with fonttools/ttx. 
> Writing out .ttf files looks to be rather complex, and there's a lot of 
> griping about the format itself to be found on the 'net. John also 
> mentioned that he'd prefer not to add the requirement of fonttools to 
> the mix from past experience.
> 
> 2. Convert the Truetype font to a Type 3 font (which is basically a set 
> of standard Postscript commands). There is a small C application 
> (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3 
> that looks to work quite well. Some modifications would have to be made 
> to actually subset the font and to integrate with Python etc., but it's 
> fairly straightforward code, and the licensing is amenable to including 
> it in the matplotlib source tree.
> 
> Clearly, I'm leaning toward option #2, but thought I'd open it to the 
> crowd to see if there are any other options or opinions on the matter.
I'm very glad to hear that you are working on this, and option #2 sounds 
good to me. Is the potential advantage of #1 better ultimate rendering 
quality? Or smaller file size?
It looks like fonttools has been untouched since 2002, correct?
> 
> The plan is to make the choice of the existing or new behavior be an 
> option, with the default TBD.
Is there any reason *not* to do the subsetting?
Eric
> 
> Cheers,
> Mike

[I've been discussing this off-list with John Hunter, and I thought I'd 
summarize that conversation in case anyone else on this list has any 
thoughts or suggestions.]
I've started working on the problem of reducing Postscript output file 
sizes by saving out only the glyphs that are used in the figure. There 
are (at least) two alternative approaches:
1. Subset the Truetype font into another Truetype font and embed it as 
we do now. This could theoretically be done with fonttools/ttx. 
Writing out .ttf files looks to be rather complex, and there's a lot of 
griping about the format itself to be found on the 'net. John also 
mentioned that he'd prefer not to add the requirement of fonttools to 
the mix from past experience.
2. Convert the Truetype font to a Type 3 font (which is basically a set 
of standard Postscript commands). There is a small C application 
(http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3 
that looks to work quite well. Some modifications would have to be made 
to actually subset the font and to integrate with Python etc., but it's 
fairly straightforward code, and the licensing is amenable to including 
it in the matplotlib source tree.
Clearly, I'm leaning toward option #2, but thought I'd open it to the 
crowd to see if there are any other options or opinions on the matter.
The plan is to make the choice of the existing or new behavior be an 
option, with the default TBD.
Cheers,
Mike

Tim,
I didn't realize you could call MainLoop() from within the main 
loop. I guess you do learn something new every day. ;-)
Anyway, Your patch has been applied in svn rev 3459. If you're 
embedding matplotlib plots in a wxPython application you really ought 
to avoid pylab. The matplotlib cookbook has some information about 
the other approaches:
	http://www.scipy.org/Cookbook/Matplotlib/EmbeddingInWx
Ken

On 7/5/07, Tom Denniston <tom...@al...> wrote:
> Oops that was the TKAgg profile results. These are the WxAgg results
> attached. Sorry about that.
>
> On 7/5/07, Tom Denniston <tom...@al...> wrote:
> > I've been trying to profile and speed up an app that uses matplotlib.
> > I tried to write an example using simple pylab commands to reproduce
> > the slowness. What I found was I could get a huge speedup just
> > avoiding unnecessary redraws. I'm down now to passable behavior.
> > Plotting 6 series in two windows takes about one and a quarter
> > seconds. I would like to improve this further, however, if it is
> > possible which is why I am posting.
What is your hold state? In your test function you may want to make
sure you are not repeatedly adding data to the same figure. Eg
p1.plot(something, hold=False)
repeated calls to plot where hold is True can cause significant
slowing... In mpl hold is True by default and in matlab it is False by
default but you can set the default as an Axes property or in your rc
file.
JDH