1. This is indeed much faster. 2. It still slows to a crawl
> as t grows. Should it? 3. The only thing that slows down is
> draw(), so the problem does not lie with the updating of the
> line instances.
No, it shouldn't get significantly slower (it doesn't on my system)
but I think I know what is wrong; in matplotlib-0.72 I introduced an
optimization to make line marker drawing much faster -
http://matplotlib.sourceforge.net/whats_new.html#0.72-line_marker_optimizations_in_agg
- but quickly had to revert it for win32 because it caused a segfault
in rare conditions, only on win32. I spent some time with Maxim, the
antigrain author, but was never able to reproduce the segfault in
standalone agg code. Last Friday I spent some time tracking it down
and with the updated information, Maxim was able to find and fix the
agg bug [Editor's note: I'm *very* proud to have found a bug in agg
code -- they are very rare critters]. So the good news is the next mpl
release will have the optimization also for win32. If you would like
to give it a test drive, there is an alpha build at
http://matplotlib.sf.net/matplotlib-0.81alpha.win32-py2.4.exe
There have been fairly significant changes at the extension code
level, so I suggest flushing your site-packages/matplotlib directory.
> P.S. Suppose I run the script and then press enter in the
> shell before closing the graph window. I get the following
> 'NULL tstate' error: Fatal Python error:
> PyEval_RestoreThread: Null tstate abnormal program
> termination Perhaps this is to be expected.
We've never been able to free ourselves of this annoyance in all the
contexts tkagg is used in (interactive, scripted, embedded,
animation). If you search the archives, you'll see numerous threads
on this one but as far as I can tell, it only happens at program
termination in interactive/animated mode and is annoying but harmless.
JDH