OK, thanks. Then it makes sense to implement blitting for the Mac OS X backend
as well.
Unfortunately I have hit one snag:
Drawing in Mac OS X / Quartz should be done from inside the event loop. You
cannot take a graphics context and just start drawing to it; the graphics
context won't be properly initialized.
In lib/matplotlib/animation.py, the actual drawing occurs here:
def _post_draw(self, framedata, blit):
# After the frame is rendered, this handles the actual flushing of
# the draw, which can be a direct draw_idle() or make use of the
# blitting.
if blit and self._drawn_artists:
self._blit_draw(self._drawn_artists, self._blit_cache)
else:
self._fig.canvas.draw_idle()
Without blitting, this function calls draw_idle on the canvas, which triggers a
call to figure.draw(renderer) from inside the event loop, which does the actual
drawing, and all is well.
With blitting, it appears that self._blit_draw starts to draw directly to the
graphics context; this won't work on Mac OS X.
Can this code be reorganized such that the blitting occurs from inside
figure.draw(renderer)? In my opinion, there is no essential difference between
blitting and other drawing functions, so to me it would make sense to have
blitting and drawing together in figure.draw(renderer).
Best,
--Michiel.
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
