Hi John, Hi the list, I almost have finished updating the
> fltkAgg, to add the new subplot formatter and the blit
> method for fast animation. Everything seems to work fine,
> but I still need to do some code clean-up, and before
> commiting the changes I have to ask what you think about
> the method I used:
Hi Gregory, Great news. Ken McIvor just emailed me this morning that
he completed the same with a _wxagg module that he will post shortly.
That means we have (or will soon have) blit methods for all GUIs
except Qt and Cocoa (gentle reminder).
> Instead of writing a special method taking account of the
> bbox for bliting, similar to the agg_to_gtk_drawable, or
> a aggcanvas->str conversion like the proposed
> aggcanvas.as_rgba_str(bbox), I just changed the method
> that I introduced for normal draw in fltkAdd, that rely
> on pytho buffer objects to transfer the agg buffer to the
> fltk library.
> The old method of the Agg backend that was used to get
> the buffer object was:
....snip...
> As fltkAgg is able to use an image source with a pixel
> stride (skipping the a of the rgba quatuor) and a line
> stride (taking a part of wide w1 from an image of wide
> w2), no copy or special method is needed with the new
> version of RendererAgg::buffer_rgba...
> Now I checked and other backends (qtagg, cocoaagg) now
> use RendererAgg::buffer_rgba. If this is ok, I will
> update all the calls to pass (0,0) instead of no
> arguments, but I wonder if the new methods could not
> simplify things for those backends too...
Yep, this all looks right. I will look into this for gtkagg as well
tomorrow. It may make rendering to a bbox even faster because gtkagg
and tkagg may both make an unnecessary copy that your method avoids.
> Another remarks is that the animation code seems quite
> fragile for the moment: if one do a resize of the output
> window, the background copy is not updated correctly and
> one have a very interresting effect 
Well, at leat I
> observe that under fltkAgg (my local version supporting
> blit) and GTKAgg. tkagg does not do this..because it is
> not possible to resize the window during animation (well,
> window is resizable but the size of the inside canvas
> does not change during this resize...).
> I think some extra steps should be performed to make
> resize and anim play nicely together (like freezing the
> anim during resize, and restarting afterwards with the
> correct background...)
What I do is connect to the new 'draw_event' which is called at the
end of Figure.draw (no GUI specific event handling required). If you
set the animated property of the Artist, and then connect your
background saver to the 'draw_event', it should handle this case.
Additionally you want to make sure your draw events are processed in
an idle queue on resizes, etc.
Check out widgets.Cursor for a complete example using draw_event
background cacheing, the guts of which are
def __init__(self, ax, useblit=False, **lineprops):
...snip
self.canvas.mpl_connect('draw_event', self.clear)
def clear(self, event):
'clear the cursor'
if self.useblit:
self.background = self.canvas.copy_from_bbox(self.ax.bbox)
Does this work for you in GTKAGG and/or FLTK? If everything looks
good, you may want to update the canonical animation examples in the
examples directory and on the wiki.
JDH
