So it seems my optimisation has an impact, although
> moderate... On the other hand, the copy mechanism induce
> some lag in the TkAgg backend, while reusing the buffer
> in FltkAgg seems a nice improvement...To check that, I
> disabled the copy in the TkAgg (tkagg.blit call), and got
> 16.4 FPS). I think thus my FltkAgg backend has the same
> speed as bare Agg, while some optim are maybe possible on
> TkAgg (if Tk can reuse an extern buffer, I am a complete
> beginner in Tk so maybe my conclusion are invalid, if
> there is a flaw in my examples...
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
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.
> Depending on what you think of that, I can submit patches
> for the Agg optimisation, exposing the Agg buffer as a
> python buffer object (allowing buffer sharing instead of
> buffer copying, if toolkit support this). For the fltk
> backend, I am ready to support it but it should wait
> acceptance of some modif I made in the python bindings of
> fltk, for now it does not work with stock pyfltk
Please send them in, either to the list or directly to Todd and
myself. Todd will be interested in anything pertaining to tkagg. 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. 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.ptr());
gdk_draw_rgb_32_image(drawable, gc, 0, 0,
block.pixelPtr = aggRenderer->pixBuffer;
where pixBuffer is the agg pixel buffer.
What does exposing the buffer in the python layer buy you?
It is best (for me) for you to submit your changes as complete files
so I can merge / compare with ediff; my dev tree is often out of sync
with the non-devel cvs tree so applying diffs is hard.