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

[Gregory L. <gre...@ff...>]

> I didn't see where the optimization was helping - could you 
> clarify? It looks like about a 5% for tkagg and there are no 
> comparisons for the fltkagg with "classic vs optimized"
> 
>   Classic TkAgg: 9.98 FPS
>   Improved TkAgg: 10.6 FPS
>   FltkAgg: 16.7 FPS

I will check the non optimized (ie with no reuse of Agg buffers) FltkAgg
backend tomorrow, but you are right, the improvement are reproductible
but small. The change for reusing buffer is trivial though, and it may
help if there is memory leak...
 
> As you may know, blitting in tk is pretty slow and there 
> doesn't appear to be anything we can do about it short of 
> some platform dependent extension code (which might be worth 
> doing at some point for linux and win32).  With your example 
> I get approx 14 FPS with tkagg on my system and 45 FPS with 
> gtkagg.  My point is that unless there are some fundamental 
> limitations in fltk as there are in tk, you might want to 
> look to gtkagg as a performance benchmark rather than tkagg. 
> gtkagg is typically 3x faster than tkagg for dynamic plots.

You are right, I should definitely install pygtk on my system to check
that, I wonder how a 3X increase in FPS is possible: after all,
de-activating blit in the TkAgg produce only a 1.5X increase (and no
image of course ;-) ): something else than Agg must hold Tk (and Fltk)
back then: I have to test the FPS one have without Agg drawing and
blitting, only canvas update, with GTK, Tk and Fltk, to be sure...

> Please send them in, either to the list or directly to Todd 
> and myself.  Todd will be interested in anything pertaining 
> to tkagg.

Ok, I send the complete relevant files as attachement tomorrow, to you
and Todd.

> I understand the rational behind not creating a 
> new agg buffer object with each draw, but at the same time 
> your numbers seem to suggest that it isn't too important, 
> performance wise.
It could be more important for GTKAgg, if it is closer to raw Agg speed
than TkAgg and FltkAgg...Something to test would be to use the Agg
backend without exporting the pixmap buffer but doing the drawing, and
check how many draw/second one can have on the examples, to really check
the penalty associated to the different toolkits, and the maximum gain
we can have by reusing Agg buffer instead of creating one for each
draw...Is this doable?

> Also, I am not sure about the necessity of 
> creating a python buffer object - perhaps you can explain 
> this a bit more.  tkagg and gtkagg both use the agg rendering 
> buffer directly with no string copy, eg
> 
>   RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());
> 
> 
> 
> //gtk
> 
>     gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
> 			  width, 
> 			  height, 
> 			  GDK_RGB_DITHER_NORMAL,
> 			  aggRenderer->pixBuffer,
> 			  width*4);
> // tk
>     block.pixelPtr =  aggRenderer->pixBuffer;
> 
> where pixBuffer is the agg pixel buffer.
> 
> What does exposing the buffer in the python layer buy you?

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

Best regards,

Greg.