From: <jgo...@gm...> - 2007-12-03 15:08:50
|
Hi, I have compiled v.0.90.1 on RHEL 5. By default, the GTKAgg backend is being used (TkAgg cannot be set, as TkInter is not installed on the system, I think. It throws a "NO Module named Tkinter" error). At any rate, a test session is as follows: import pylab pylab.plot ( [1,2,3],[1,2,3],'-or') #Wait for a long time, up to 3-4 minutes pylab.show() # Display the graph. Quite fast <1sec This delay is very unusual, and does not happen on my laptop. Does anyone have any ideas? Thanks! Jose |
From: John H. <jd...@gm...> - 2007-12-04 03:25:18
|
On Dec 3, 2007 9:08 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > Hi, > I have compiled v.0.90.1 on RHEL 5. By default, the GTKAgg backend is bei= ng > used (TkAgg cannot be set, as TkInter is not installed on the system, I > think. It throws a "NO Module named Tkinter" error). > > At any rate, a test session is as follows: > import pylab > pylab.plot ( [1,2,3],[1,2,3],'-or') #Wait for a long time, up to 3-4 minu= tes > pylab.show() # Display the graph. Quite fast <1sec > > This delay is very unusual, and does not happen on my laptop. Does anyone= have > any ideas? This is not happening for me. Does it happen every time you run mpl or just the first time after you install. Run some test script, eg > cat test.py from pylab import * plot([1,2,3]) show() with > python test.py -dGTKAgg --verbose-debug and see if you can get some clue what mpl is doing when it hangs. Also, post the verbose output to the list. Thanks, JDH |
From: <jgo...@gm...> - 2007-12-04 10:57:23
|
Sm9obiwKCk9uIFR1ZXNkYXkgMDQgRGVjZW1iZXIgMjAwNyAwMzoyNToxNSBKb2huIEh1bnRlciB3 cm90ZToKPiBPbiBEZWMgMywgMjAwNyA5OjA4IEFNLCBKb3PpIEfzbWV6LURhbnMgPGpnb21lemRh bnNAZ21haWwuY29tPiB3cm90ZToKPiA+IEkgaGF2ZSBjb21waWxlZCB2LjAuOTAuMSBvbiBSSEVM IDUuIEJ5IGRlZmF1bHQsIHRoZSBHVEtBZ2cgYmFja2VuZCBpcwo+ID4gYmVpbmcgdXNlZCAoVGtB Z2cgY2Fubm90IGJlIHNldCwgYXMgVGtJbnRlciBpcyBub3QgaW5zdGFsbGVkIG9uIHRoZQo+ID4g c3lzdGVtLCBJIHRoaW5rLiBJdCB0aHJvd3MgYSAiTk8gTW9kdWxlIG5hbWVkIFRraW50ZXIiIGVy cm9yKS4KPiBUaGlzIGlzIG5vdCBoYXBwZW5pbmcgZm9yIG1lLiAgRG9lcyBpdCBoYXBwZW4gZXZl cnkgdGltZSB5b3UgcnVuIG1wbAo+IG9yIGp1c3QgdGhlIGZpcnN0IHRpbWUgYWZ0ZXIgeW91IGlu c3RhbGwuICBSdW4gc29tZSB0ZXN0IHNjcmlwdCwgZWcKClRoYW5rcyBmb3IgeW91ciByZXBseS4g SSB0aGluayBpdCBtaWdodCB3ZWxsIGJlIGEgZm9udHMgcHJvYmxlbS4gSGVyZSdzIHRoZSAKdGVz dCBzY3JpcHQsIHBsdXMgYSBjb21tZW50IHdoZXJlIHRoZSBiaWcgZGVsYXkgaGFwcGVuczoKJSBj YXQgdGVzdC5weSAKZnJvbSBweWxhYiBpbXBvcnQgKgpwbG90KFsxLDIsM10pCnNob3coKQpjaGVy cnklIHB5dGhvbiB0ZXN0LnB5IC1kR1RLQWdnIC0tdmVyYm9zZS1kZWJ1ZwptYXRwbG90bGliIGRh dGEgcGF0aCAvdXNyL2xpYi9weXRob24yLjQvc2l0ZS1wYWNrYWdlcy9tYXRwbG90bGliL21wbC1k YXRhCiRIT01FPS9ob21lL3VjZmFqbGcKQ09ORklHRElSPS9ob21lL3VjZmFqbGcvLm1hdHBsb3Rs aWIKbG9hZGVkIHJjIApmaWxlIC91c3IvbGliL3B5dGhvbjIuNC9zaXRlLXBhY2thZ2VzL21hdHBs b3RsaWIvbXBsLWRhdGEvbWF0cGxvdGxpYnJjCm1hdHBsb3RsaWIgdmVyc2lvbiAwLjkwLjEKdmVy Ym9zZS5sZXZlbCBkZWJ1ZwppbnRlcmFjdGl2ZSBpcyBGYWxzZQp1bml0cyBpcyBUcnVlCnBsYXRm b3JtIGlzIGxpbnV4Mgpsb2FkZWQgbW9kdWxlczogClsncHlsYWInLCAnX2Jpc2VjdCcsICdfX2Z1 dHVyZV9fJywgJ2NvcHlfcmVnJywgJ3NyZV9jb21waWxlJywgJ2Rpc3R1dGlscycsICdpdGVydG9v bHMnLCAnX3NyZScsICdqYXBhbmVzZS5hbGlhc2VzJywgJ3NpdGUnLCAnX19idWlsdGluX18nLCAn ZGF0ZXRpbWUnLCAnZGlzdHV0aWxzLnJlJywgJ21hdHBsb3RsaWIucmUnLCAnbWF0cGxvdGxpYi50 ZW1wZmlsZScsICdlbmNvZGluZ3MnLCAncHl0ei5kYXRldGltZScsICdzaHV0aWwnLCAnZGlzdHV0 aWxzLnN0cmluZycsICdkaXN0dXRpbHMub3MnLCAnZGF0ZXV0aWwnLCAnbWF0cGxvdGxpYi5kYXRl dGltZScsICdwb3NpeHBhdGgnLCAnX3JhbmRvbScsICd0ZW1wZmlsZScsICdlcnJubycsICdtYXRw bG90bGliLndhcm5pbmdzJywgJ2JpbmFzY2lpJywgJ2VuY29kaW5ncy5jb2RlY3MnLCAnc3JlX2Nv bnN0YW50cycsICdyZScsICdtYXRwbG90bGliLm1kNScsICdvcy5wYXRoJywgJ3B5dHouc3lzJywg J19jb2RlY3MnLCAnZGlzdHV0aWxzLnN5c2NvbmZpZycsICdlbmNvZGluZ3MuZXhjZXB0aW9ucycs ICdweXR6LnNldHMnLCAnbWF0aCcsICdmY250bCcsICdzdGF0JywgJ3ppcGltcG9ydCcsICdzdHJp bmcnLCAnd2FybmluZ3MnLCAnZW5jb2RpbmdzLnR5cGVzJywgJ1VzZXJEaWN0JywgJ2VuY29kaW5n cy51dGZfOCcsICdtYXRwbG90bGliJywgJ2phcGFuZXNlJywgJ3N5cycsICdqYXBhbmVzZS5hbGlh c2VzLmVuY29kaW5ncycsICdweXR6LnR6aW5mbycsICdweXR6JywgJ19fbWFpbl9fJywgJ21hdHBs b3RsaWIuX19mdXR1cmVfXycsICdjb2RlY3MnLCAnbWF0cGxvdGxpYi5zeXMnLCAnbWF0cGxvdGxp Yi5weXR6JywgJ3R5cGVzJywgJ21kNScsICdtYXRwbG90bGliLmRhdGV1dGlsJywgJ21hdHBsb3Rs aWIub3MnLCAndGhyZWFkJywgJ3NyZScsICdiaXNlY3QnLCAnbWF0cGxvdGxpYi5kaXN0dXRpbHMn LCAnc2lnbmFsJywgJ2Rpc3R1dGlscy5lcnJvcnMnLCAncmFuZG9tJywgJ2xpbmVjYWNoZScsICdt YXRwbG90bGliLnNodXRpbCcsICdwb3NpeCcsICdlbmNvZGluZ3MuYWxpYXNlcycsICdzZXRzJywg J2V4Y2VwdGlvbnMnLCAnc3JlX3BhcnNlJywgJ3B5dHouYmlzZWN0JywgJ2Rpc3R1dGlscy5zeXMn LCAnb3MnLCAnc3Ryb3AnXQpudW1lcml4IG51bXB5IDEuMC40CmZvbnQgc2VhcmNoIHBhdGggClsn L3Vzci9saWIvcHl0aG9uMi40L3NpdGUtcGFja2FnZXMvbWF0cGxvdGxpYi9tcGwtZGF0YS9mb250 cy90dGYnLCAnL3Vzci9saWIvcHl0aG9uMi40L3NpdGUtcGFja2FnZXMvbWF0cGxvdGxpYi9tcGwt ZGF0YS9mb250cy9hZm0nXQp0cnlpbmcgCmZvbnRuYW1lIC91c3IvbGliL3B5dGhvbjIuNC9zaXRl LXBhY2thZ2VzL21hdHBsb3RsaWIvbXBsLWRhdGEvZm9udHMvdHRmL2Ntc3kxMC50dGYKdHJ5aW5n IApmb250bmFtZSAvdXNyL2xpYi9weXRob24yLjQvc2l0ZS1wYWNrYWdlcy9tYXRwbG90bGliL21w bC1kYXRhL2ZvbnRzL3R0Zi9WZXJhU2VCZC50dGYKdHJ5aW5nIApmb250bmFtZSAvdXNyL2xpYi9w eXRob24yLjQvc2l0ZS1wYWNrYWdlcy9tYXRwbG90bGliL21wbC1kYXRhL2ZvbnRzL3R0Zi9jbXIx MC50dGYKdHJ5aW5nIApmb250bmFtZSAvdXNyL2xpYi9weXRob24yLjQvc2l0ZS1wYWNrYWdlcy9t YXRwbG90bGliL21wbC1kYXRhL2ZvbnRzL3R0Zi9jbWV4MTAudHRmCnRyeWluZyAKZm9udG5hbWUg L3Vzci9saWIvcHl0aG9uMi40L3NpdGUtcGFja2FnZXMvbWF0cGxvdGxpYi9tcGwtZGF0YS9mb250 cy90dGYvVmVyYS50dGYKbG9hZGVkIHR0ZmNhY2hlIGZpbGUgL2hvbWUvdWNmYWpsZy8ubWF0cGxv dGxpYi90dGZmb250LmNhY2hlCmJhY2tlbmQgR1RLQWdnIHZlcnNpb24gMi4xMC4xClsuLi4gQklH IERFTEFZLi4uLl0KICAgICAgICBmaW5kZm9udCBmYWlsZWQgQml0c3RyZWFtIFZlcmEgU2VyaWYs IE5ldyBDZW50dXJ5IFNjaG9vbGJvb2ssIENlbnR1cnkgClNjaG9vbGJvb2sgTCwgVXRvcGlhLCBJ VEMgQm9va21hbiwgQm9va21hbiwgTmltYnVzIFJvbWFuIE5vOSBMLCBUaW1lcyBOZXcgClJvbWFu LCBUaW1lcywgUGFsYXRpbm8sIENoYXJ0ZXIsIHNlcmlmCkNvdWxkIG5vdCBtYXRjaCBCaXRzdHJl YW0gVmVyYSBTZXJpZiwgTmV3IENlbnR1cnkgU2Nob29sYm9vaywgQ2VudHVyeSAKU2Nob29sYm9v ayBMLCBVdG9waWEsIElUQyBCb29rbWFuLCBCb29rbWFuLCBOaW1idXMgUm9tYW4gTm85IEwsIFRp bWVzIE5ldyAKUm9tYW4sIFRpbWVzLCBQYWxhdGlubywgQ2hhcnRlciwgc2VyaWYsIG5vcm1hbCwg bm9ybWFsLiAgClJldHVybmluZyAvdXNyL2xpYi9weXRob24yLjQvc2l0ZS1wYWNrYWdlcy9tYXRw bG90bGliL21wbC1kYXRhL2ZvbnRzL3R0Zi9WZXJhLnR0ZgoKClNvLCBpdCdzIG5vdCBmaW5kaW5n IGFueSBvZiB0aGUgZm9udHMgYWJvdmUsIGFuZCBjb21pbmcgdXAgd2l0aCBWZXJ0YS50dGYuIApD b3VsZCB0aGlzIGJlIHRoZSBwcm9ibGVtPyBBbmQgaWYgaXQgaXMsIHdoYXQgY2FuIEkgZG8gdG8g c29sdmUgaXQ/CgpUaGFua3MhCkpvc2UK |
From: John H. <jd...@gm...> - 2007-12-04 14:08:02
|
On Dec 4, 2007 4:50 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > Thanks for your reply. I think it might well be a fonts problem. Here's t= he > test script, plus a comment where the big delay happens: > % cat test.py > from pylab import * > plot([1,2,3]) > show() Two more tests. WIll you set the debug level to --verbose-debug-annoying and add a savefig command to your script, eg savefig('myfig') with no extension (the backend will provide a default extension with the -d flags below). Try running the script in three modes -dPS, -dAgg and -dGTKAgg and let us know if the lag is in all three and if not in which one(s). Then repost the debug output and insert a comment where the lag is occurring. Thanks, JDH |
From: <jgo...@gm...> - 2007-12-04 14:23:50
|
John, On Tuesday 04 December 2007 14:07:36 you wrote: > Two more tests. WIll you set the debug level to > --verbose-debug-annoying and add a savefig command to your script, eg > savefig('myfig') with no extension (the backend will provide a default > extension with the -d flags below). Try running the script in three > modes PS and Agg work fast enough, and produce meaningful PS and PNG output files (as well as popping up a window with the plot). GTKAgg is the one taking a long time to pop up, AND results in an empty PNG file. I am attaching the debug output of the GTKAgg mode. (Delay occurs @ #[... DELAY....] line. % cat test.py from pylab import * plot([1,2,3]) show() savefig("myfig") % python test.py -dGTKAgg --verbose-debug-annoying matplotlib data path /usr/lib/python2.4/site-packages/matplotlib/mpl-data $HOME=/home/ucfajlg CONFIGDIR=/home/ucfajlg/.matplotlib loaded rc file /usr/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc matplotlib version 0.90.1 verbose.level debug-annoying interactive is False units is True platform is linux2 loaded modules: ['pylab', '_bisect', '__future__', 'copy_reg', 'sre_compile', 'distutils', 'itertools', '_sre', 'japanese.aliases', 'site', '__builtin__', ' datetime', 'distutils.re', 'matplotlib.re', 'matplotlib.tempfile', 'encodings', 'pytz.datetime', 'shutil', 'distutils.string', 'distutils.os', 'dateutil', ' matplotlib.datetime', 'posixpath', '_random', 'tempfile', 'errno', 'matplotlib.warnings', 'binascii', 'encodings.codecs', 'sre_constants', 're', 'matplotlib .md5', 'os.path', 'pytz.sys', '_codecs', 'distutils.sysconfig', 'encodings.exceptions', 'pytz.sets', 'math', 'fcntl', 'stat', 'zipimport', 'string', 'warnin gs', 'encodings.types', 'UserDict', 'encodings.utf_8', 'matplotlib', 'japanese', 'sys', 'japanese.aliases.encodings', 'pytz.tzinfo', 'pytz', '__main__', 'ma tplotlib.__future__', 'codecs', 'matplotlib.sys', 'matplotlib.pytz', 'types', 'md5', 'matplotlib.dateutil', 'matplotlib.os', 'thread', 'sre', 'bisect', 'mat plotlib.distutils', 'signal', 'distutils.errors', 'random', 'linecache', 'matplotlib.shutil', 'posix', 'encodings.aliases', 'sets', 'exceptions', 'sre_parse ', 'pytz.bisect', 'distutils.sys', 'os', 'strop'] numerix numpy 1.0.4 font search path ['/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf', '/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/afm'] trying fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/cmsy10.ttf trying fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/VeraSeBd.ttf trying fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/cmr10.ttf trying fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/cmex10.ttf trying fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf loaded ttfcache file /home/ucfajlg/.matplotlib/ttffont.cache backend GTKAgg version 2.10.1 # [.... DELAY ....] FigureCanvasAgg.draw RendererAgg.__init__ RendererAgg.__init__ width=640.0, height=480.0 RendererAgg.__init__ _RendererAgg done RendererAgg.__init__ done RendererAgg._get_agg_font findfont failed Bitstream Vera Serif, New Century Schoolbook, Century Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times New Roma n, Times, Palatino, Charter, serif Could not match Bitstream Vera Serif, New Century Schoolbook, Century Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times New Roman, Times , Palatino, Charter, serif, normal, normal. Returning /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg.points_to_pixels RendererAgg.points_to_pixels RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg.points_to_pixels RendererAgg.points_to_pixels RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg.points_to_pixels RendererAgg.points_to_pixels RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg.points_to_pixels RendererAgg.points_to_pixels RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg.points_to_pixels RendererAgg.points_to_pixels RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg.points_to_pixels RendererAgg.points_to_pixels RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg._get_agg_font RendererAgg.draw_text RendererAgg._get_agg_font FigureCanvasAgg.buffer_rgba RendererAgg.buffer_rgba FigureCanvasAgg.print_figure FigureCanvasAgg.draw RendererAgg.__init__ RendererAgg.__init__ width=800.0, height=600.0 RendererAgg.__init__ _RendererAgg done RendererAgg.__init__ done |
From: John H. <jd...@gm...> - 2007-12-04 14:27:54
|
On Dec 4, 2007 8:23 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > PS and Agg work fast enough, and produce meaningful PS and PNG output fil= es > (as well as popping up a window with the plot) Wait a minute, if you are getting a plot window when you pass -dPS or -dAgg, something very odd is happening and likely points to what is causing your real problem. It means some other GUI toolkit is getting activated and the slowness you are seeing is resulting from a conflict between mainloops, most likely. If this is indeed the case, please run with either -dAgg or -sPS and post the full debug annoying output. Also, post the exact script you are running.... JDH |
From: John H. <jd...@gm...> - 2007-12-04 14:27:22
|
On Dec 4, 2007 8:23 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > PS and Agg work fast enough, and produce meaningful PS and PNG output fil= es > (as well as popping up a window with the plot) Wait a minute, if you are getting a plot window when you pass -dPS or -dAgg, something very odd is happening and likely points to what is causing your real problem. It means some other GUI toolkit is getting activated and the slowness you are seeing is resulting from a conflict between mainloops, most likely. If this is indeed the case, please run with either -dAgg or -sPS and post the full debug annoying output. Also, post the exact script you are running.... JDH |
From: <jgo...@gm...> - 2007-12-04 15:08:22
|
On Tuesday 04 December 2007 14:27:21 you wrote: > On Dec 4, 2007 8:23 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > > PS and Agg work fast enough, and produce meaningful PS and PNG output > > files (as well as popping up a window with the plot) > > Wait a minute, if you are getting a plot window when you pass -dPS or > -dAgg, something very odd is happening and likely points to what is > causing your real problem. It means some other GUI toolkit is getting > activated and the slowness you are seeing is resulting from a conflict > between mainloops, most likely. If this is indeed the case, please > run with either -dAgg or -sPS and post the full debug annoying output. Sorry, my wrong. There's no such window when running with Agg. There was=20 another window from another session which I mistakenly thought had to do wi= th=20 these tests. Agg and PS produce PNG and PS files respectively, with no wind= ow=20 popping up. Apologies for that. > Also, post the exact script you are running.... It is in the beginning of my debug output, but I'll re-send the script and= =20 command line: *script (test.py): from pylab import * plot([1,2,3]) show() savefig("myfig") *command line: python test.py -dGTKAgg --verbose-debug-annoying Thanks, J |
From: <jgo...@gm...> - 2007-12-04 15:20:06
|
On Tuesday 04 December 2007 15:13:21 you wrote: > OK, the delay comes before draw which is an important piece of > information. What happens if you run these two scripts. Do you get > the delay? > > # script 1 (no plot) > from pylab import * No delay. Debug output stops at line "backend GTKAgg version 2.10.1", but returns to prompt. I'd say this works as expected. > # script2 (no show) > from pylab import * > plot([1,2,3]) Delay. Delay on the same bit I commented on before (see the previous debug output). So no need to wait for the show() call to get to the error, I guess... Thanks |
From: John H. <jd...@gm...> - 2007-12-04 15:31:07
|
On Dec 4, 2007 9:19 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > On Tuesday 04 December 2007 15:13:21 you wrote: > > OK, the delay comes before draw which is an important piece of > > information. What happens if you run these two scripts. Do you get > > the delay? > > > > # script 1 (no plot) > > from pylab import * > > No delay. Debug output stops at line "backend GTKAgg version 2.10.1", bu= t > returns to prompt. I'd say this works as expected. > > > # script2 (no show) > > from pylab import * > > plot([1,2,3]) What about these scripts # just make a figure from pylab import * figure() # just make a subplot from pylab import * subplot(111) I'm trying to narrow down where the problem is occurring and am still stumped as to the explanation... |
From: <jgo...@gm...> - 2007-12-04 15:39:43
|
On Tuesday 04 December 2007 15:31:04 John Hunter wrote: > What about these scripts > > # just make a figure > from pylab import * > figure() Takes a long time. > # just make a subplot > from pylab import * > subplot(111) Takes a long time. > I'm trying to narrow down where the problem is occurring and am still > stumped as to the explanation... I've used MPL in a few system, and it is only on this particular one that it has this delay! Incidentally, do you want the debug output from these two scripts? They essentially the same as the ones I sent before (up to backend GTKAgg version 2.10.1, where the output stops, and after a while, we're back at the command line). Thanks, J |
From: John H. <jd...@gm...> - 2007-12-04 15:54:23
|
On Dec 4, 2007 9:39 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > On Tuesday 04 December 2007 15:31:04 John Hunter wrote: > > What about these scripts > > > > # just make a figure > > from pylab import * > > figure() > > Takes a long time. OK, it is in the gtk figure creation code. Get the matplotlib examples directory and try running examples/embedding_in_gtk.py which does not use pylab but instead does all the gtk stuff manually. See if you can reproduce the error. If so, slowly remove or comment out parts of the code until you get the minimal script which reproduces the slowness and then send it my way with commentary. It looks like you may have something wrong with your gtk installation but it is hard to say. JDH |
From: <jgo...@gm...> - 2007-12-04 16:00:40
|
On Tuesday 04 December 2007 15:54:17 you wrote: > OK, it is in the gtk figure creation code. Get the matplotlib > examples directory and try running examples/embedding_in_gtk.py which > does not use pylab but instead does all the gtk stuff manually. See > if you can reproduce the error. If so, slowly remove or comment out > parts of the code until you get the minimal script which reproduces > the slowness and then send it my way with commentary. It looks like > you may have something wrong with your gtk installation but it is hard > to say. Interestingly enough, the embedding_in_gtk.py script works perfectly (takes less than a second to run), so I am not able to reproduce the slowness! Thanks! |
From: John H. <jd...@gm...> - 2007-12-04 16:05:40
|
On Dec 4, 2007 10:00 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > Interestingly enough, the embedding_in_gtk.py script works perfectly (tak= es > less than a second to run), so I am not able to reproduce the slowness! Hmm, the plot thickens. How about embedding_in_gtk2.py -- this add the too= lbar JDH |
From: <jgo...@gm...> - 2007-12-04 16:16:15
|
On Tuesday 04 December 2007 16:05:33 John Hunter wrote: > On Dec 4, 2007 10:00 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > > Interestingly enough, the embedding_in_gtk.py script works perfectly > > (takes less than a second to run), so I am not able to reproduce the > > slowness! > > Hmm, the plot thickens. How about embedding_in_gtk2.py -- this add the > toolbar This does indeed slow things down. The minimal script that reproduces this= =20 behaviour is the following (the delay appears round about the definition of= =20 toolbar): import gtk from matplotlib.axes import Subplot from matplotlib.figure import Figure from numpy import arange, sin, pi from matplotlib.backends.backend_gtk import FigureCanvasGTK as FigureCanvas from matplotlib.backends.backend_gtk import NavigationToolbar2GTK \ as NavigationToolbar win =3D gtk.Window() win.connect("destroy", lambda x: gtk.main_quit()) win.set_default_size(400,300) win.set_title("Embedding in GTK") fig =3D Figure(figsize=3D(5,4), dpi=3D100) canvas =3D FigureCanvas(fig) toolbar =3D NavigationToolbar(canvas, win) # ^ Delay appears here win.add(toolbar) win.show_all() gtk.main() |
From: <jgo...@gm...> - 2007-12-05 14:59:04
|
On Tuesday 04 December 2007 16:16:06 Jos=E9 G=F3mez-Dans wrote: > On Tuesday 04 December 2007 16:05:33 John Hunter wrote: > > On Dec 4, 2007 10:00 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wro= te: > > Hmm, the plot thickens. How about embedding_in_gtk2.py -- this add the > > toolbar > > This does indeed slow things down. The minimal script that reproduces this > behaviour is the following (the delay appears round about the definition = of > toolbar): [...] Mmmm... I was just wondering whether compiling the new 0.91.1 version might= =20 make the problem go away? I am currently running 0.90.1. Thanks, J |
From: John H. <jd...@gm...> - 2007-12-05 15:08:12
|
On Dec 5, 2007 8:58 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote: > Mmmm... I was just wondering whether compiling the new 0.91.1 version mig= ht > make the problem go away? I am currently running 0.90.1. Unlikely, we haven't changed anything in that code. One thing you can do, it is fairly labor intensive, is to paste the toolbar code from backend_gtk into your script and slowly start hacking away at it to see which gtk call is causing your problems. I don't see an easier way. Alternatively, you could get tkagg, qtagg or wxagg installed. If you want to stick with gtk, I can provide a sample script for you that defines the toolbar inline so you can hack on it. JDH |