Re : [matplotlib-devel] Re: Speed of dynamic_image

[John H. <jdh...@ac...>]

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> You are right, I should definitely install pygtk on my
    Gregory> system to check that, I wonder how a 3X increase in FPS
    Gregory> is possible: after all, de-activating blit in the TkAgg
    Gregory> produce only a 1.5X increase (and no image of course ;-)

The gtk advantage over tk depends on the example.  For images (eg
for Andrew's dynamic image) the advantage is approx 1.5x.  For the
simple line drawing dyanmic example you posted, it's about 3x.  I
suppose the difference is that in the image example, there is a much
larger, shared computational burden in agg, whereas with the simple
line drawing example the blitting difference is more pronounced.

    Gregory> It could be more important for GTKAgg, if it is closer to
    Gregory> raw Agg speed than TkAgg and FltkAgg...Something to test
    Gregory> would be to use the Agg backend without exporting the
    Gregory> pixmap buffer but doing the drawing, and check how many
    Gregory> draw/second one can have on the examples, to really check
    Gregory> the penalty associated to the different toolkits, and the
    Gregory> maximum gain we can have by reusing Agg buffer instead of
    Gregory> creating one for each draw...Is this doable?

I'm certainly happy to try it.  One last thing you may want to do
before sending in your updates tomorrow is to run backend_driver.py in
the examples subdir to make sure your changes don't create any
problems with the known examples.

    Gregory> In these cases nothing performance wise, in fact the way
    Gregory> you use should me marginally faster (avoiding the
    Gregory> creation/destruction of python buffer objects ).  Python
    Gregory> buffer objects is a way for me to implement the transfer
    Gregory> without copy of the Agg buffer to fltk in more "abstract"
    Gregory> way: no need to implement a c extension that know both
    Gregory> the internals of agg and fltk, I split it using the
    Gregory> python buffer as a standard protocol (buffer objects were
    Gregory> intended for just this use, I think...).  This is not
    Gregory> very important, but it could simplify things if there is
    Gregory> multiple renderer and multiple toolkits to bind...like if
    Gregory> alternative to Agg is implemented (or multiple version of
    Gregory> Agg must be supported)...and I guess that the overhead of
    Gregory> this creation/destruction of python buffer objects is
    Gregory> really negligeable.

Another area it may help is in backend_gtk and backend_wx, which *do*
use string methods to access the agg image buffer.

JDH