matplotlib-devel Mailing List for matplotlib

Hi Michiel,

On 13.04.2013, at 1:30AM, Michiel de Hoon wrote:

> The slow speed for long paths like the one in your example was due to a limitation to Quartz itself. This was solved by breaking the path up into subpaths of up to 100 points. But you mentioned that releases before 1.2 were not slow (and I verified this with matplotlib 1.1.1), suggesting that something else is going on. Can you check which change between 1.1.1 and 1.2 is causing the slowdown for your example?

It's the passing of set_dpi (commit 6533674) - that's still unchanged in master,
but I don't see any speed penalty compared to 1.1.1 any more. I don't know if
the change you mentioned above completely fixed this or just made up for it
by speeding it up otherwise…
I have just merged all updates to backend_maxosx.py and _macosx.m back
into 1.2.1, and this seems to solve the issue and passes all tests as well.

Cheers,
					Derek

Dear all,

The animation code in matplotlib relies on timers to update the animated figures. Currently a new timer is created by calling new_timer on a canvas, as in

>>> f = pylab.figure()
>>> timer = f.canvas.new_timer()

This seems a bit of a wrinkle. For example, you may want to associate a timer with multiple figures, or with no figure at all; also you may want to continue using a timer after a particular figure is closed.

I would therefore propose to make timers independent of canvases. Something like this:

>>> from matplotlib import events
>>> timer = events.Timer()

This has the additional advantage of making the different backends more similar to each other; in the current implementation some backends rely on the canvas when making a timer, while others ignore it.

I have made a branch on github that does exactly this; see
https://github.com/mdehoon/matplotlib/tree/Timer
I have verified that the animation examples still work correctly with all backends.

Any comments/suggestions/criticisms? If this seems a good idea, I can make a pull request.

Best,
-Michiel.

http://blogs.hbr.org/cs/2013/04/the_science_of_what_we_do_and_dont_know_about_data_visualization.html