Faster plotting library

[Jacob Hinkle]

The images produced by PyCA.Display using matplotlib are very nice, publication-quality, and easy to save to PDF or PNG. But the big drawback is the matplotlib is SLOW. I am toying with the idea of having a separate python plotting library, compatible with PyCA.Display for doing faster, interactive plotting. Ideally we'd be able to just do

#import PyCA.Display as display
import PyCA.FastDisplay as display

As for what toolkit to use, I think Chaco looks interesting. An obvious problem is that commonly our application code does some management of plotting layouts, for instance it raises a figure, clears it, sets titles, does subplots, etc all using the matplotlib interface. It may be impractical to implement, but I wanted to throw it out there and maybe get some feedback of whether the slow plotting is really annoying to everyone else.

[Jacob Hinkle]

I just found out about glumpy as well. It might be easier to convert since it uses numpy as well and looks to be much more compatible with matplotlib

[Jacob Hinkle]

Oh boy, now I'm excited. glumpy uses OpenGL textures to render everything 2D float arrays. I am wondering now if we could do something really slick and code the transfers to texture memory directly, so that if you have an Image3D on the GPU and call dispImage(I) it never actually pulls it down to host memory. Of course plotting deformations, quiver plots, etc is probably always going to be slower, but those might benefit at some point from writing an extractslice function that does the slicing (and maybe downsampling) on the GPU before copying to host.

[Sam Preston]

I agree that the slow plotting can be annoying, but it's not high-priority for me. I tend to just update the plots every N iterations so that the plotting doesn't bog the whole process down too much. That being said, if we had a quick slice plotting function I'd definitely use it. I don't think we want to try to replicate our matplotlib-based functions (just too much overhead for little benefit). If we just had a QuickDispImage function (and maybe QuickPlot for plotting energy) that would probably be enough.

We could definitely do the transfer from global to texture memory (texture memory is actually just global memory with some extra alignment constraints), but the speed issues don't come from the transfer, it's relatively quick (especially if just transferring a slice, which is generally what we want to see).

[Jacob Hinkle]

Yeah you're prob right about the overhead of trying to replicate the stuff in there already. Do you think glumpy would be useful for QuickDispImage? Not sure what's good for quick line plots.

[Jacob Hinkle]

We can always reopen this later, but I'd say the current plotting is good and if we need it to be faster for some application, we develop it there and copy into pyca as necessary.