Hey Travis, Travis Oliphant <oliphant@ee.byu.edu> wrote ..
Hi all,
I know the subject of contouring has come up a time or two. It has been mentioned that GIST has a good contouring algorithm. While I can't speak to the quality of a contouring algorithm at this point, I can let you know that the contour algorithm is exposed to Python in xplt.
It is xplt.contour
With this routine you can take a 2-D array, define a level and it will spit out points (xc,yc) which define the contour. It appears to be very fast as well.
Cool.
Chaco is coming along. I would like to help it grow though it is difficult to come up to speed with all the fancy threading and object class proxying that is going on. Plus, I still get occasional segfaults which I can't track the source of.
This stuff is only needed for using it with wxPython in a non-wxPython shell. I've been using PyCrust lately with much success. In the past, I also used gui_thread+scipy.plt from windows on a daily basis without major issues. That said, gui_thread is a huge hack. It is needed to get around wxPython issues with multiple threads. It's cool how it works, but it isn't very pretty, and it has never been particularly reliable on X because of these weird async errors, etc. gui_thread can be improved, probably to the point of robustness, by building the proxies directly into the wxPython shadow classes instead of a putting an extra proxy on top of them. Further, there are several new (at least since gui_thread was written) mutex functions exposed by wxPython that could be used in the proxies. I'm happy to point the way if someone wants to attack this, but no one here has time to look at it. We are using Chaco from wxpython shells or in wxPython apps almost exclusively right now so that is where most of the effort is going -- although Dave continues to propagate as many changes as possible to the TkInter/OpenGL implementation as well as keeping the hard copy output stuff working. We would very much appreciate someone picking up support of TkInter as we really want to support but don't have the resources at the moment.
One concern I have is whether or not it will ever be fast. Right now, the update that occurs when scrolling a sliding bar in the wxplot demo is annoyingly slow (long flashes everytime the sliding bar is touched).
I agree it is slow. I am not, however, concerned whether it will ever be fast. Kiva is a PDF based drawing state machine that is currently completely implemented in Python. Moving the state machine to C will make it fast. With the eventual addition of "compiled paths," the Python calls to create a path can be called once and then forever stored as a C/C++ struct that is executed by the C/C++ state machine. This is a reasonable path to a fast implementation. In the future, we plan on using the anti-grain library at the C/C++ to draw to a memory buffer (Numeric array masquerading as a bitmap) that is blitted to the canvas. Again, this is a reasonable path to speed. It will also simplify the support of new rendering engines because only the blit of a buffer to a new backend is required to add support. One other slow part at the moment is the freetype implementation. I have played with caching and seen speed ups for drawing text of 3-10 times. The code is not production though, and I don't have time now to produce a production solution. One comment other comment on speed -- I have used Chaco extensively on a modern laptop with WinXP the last week or so. While the scrolling redraw is noticable, it is not debilitatingly so. Perhaps this is one of the reasons we continue to address other issues as higher priorities. I know this is of little consolation if you're on an older machine... We continue to work on different issues because they are more important to us. We would be very excited to have someone implement the optimizations to Kiva (and clean it up in general) as there are plenty of other things to work on. While it is on our todo list, noone is working on it right now. Maybe in a few weeks -- maybe not. I am very hopeful it will be within a few months though.
Right now, I'm comfortable with xplt and can do any number of graphs and it is very flexible and VERY FAST.
Great. There are multiple other reasonable solutions out there that others really like, and I'm glad they are there to fill the gap until Chaco is ready.
Plotting is such a hang-up right now for the adoption of SciPy that I wonder if it wouldn't be wise to port xplt to Windows (I actually don't think it would take that long and I could hire a student to do over the next few months).
It could be worth it. I would suggest that implementing an anti-grain backend for Kiva is a better use of time, and also doable in a reasonably short amount of time. David Ascher implemented partial (but very adequate) PIL and PS backends in about a week I believe. Anti-grain is more work, but easily doable in a few months effort. Still, I'm not against porting xplt if you would like to, it just isn't that useful in my mind for the long term.
It's not the ideal long-term solution but it would give us a known, fast plotting interface (kind of like Matlab 4.2 plotting) for simple plots and we could then continue to develop chaco as the long-term solution without losing valuable potential contributors who can't find the plotting package, or get it to work.
Perhaps all of this is already available with gnuplot and we just need to do a better job of interfacing with it, but I'm not sure.
Either of these are fine by me.
Anyway, I guess I'm venting a little frustration that it is very difficult for me to get chaco working stably and well to do anything more than a few gimmick plots rather slowly, when xplt has worked reliably for me for several years and is working quite well to do all sorts of visualization, yet nobody seems to want to use it but me.
While our end goals are the same, I think our time tolerances are not. We are building a highly interactive, well designed, plotting tool that works across a huge array of scientific fields and can easily be dropped into GUI apps as well as used for day-to-day graphing. This sort of thing takes time -- more than I originally anticipated, but still, anything less than this is not worth spending time on to me. We're not gonna cut any corners. So, it may be 6 or even more months before Chaco meets your needs -- and maybe it never will if the gui_thread isn't worked out, and PyCrust (hopefully combined with IPython in the future) isn't an acceptable shell. I'm sorry your frustrated with the speed of Chaco's progress, its lack of robustness on your platform, and the difficulty your having contributing to it even though you wish to. I wish I could say at least one of these will change in the near future, but I can't. Dave is working full time on the project and he is making some amazing progress in important areas. Even though your struggling to get simple, slow and crashing plots out of it, in Dave's hands, it is capable of truely amazing things with extremely little code. His focus remains honing this portion of the library and working on the interface. Maybe some documentation will work its way in there too... In summary, I would prefer to see a unified graphics effort with a goal of getting Chaco "fast enough" sooner rather than later. But, I also realize the timeline may not meet your needs. I don't see porting xplt to windows as significantly better than the options already there (DISLIN, GnuPlot, etc.), but perhaps it is. regards, eric
I'll get back to hacking now.
-teo