On Dec 30, 2007 12:33 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > We should have gotten involved more in matplotlib development earlier, > but at least now. I think there should be just one 3D plotting > library in Python and imho matplotlib should do it. However, we need:
Hi Ondrej, Sorry for the delay getting back to you. I've been on holiday so have only limited email access. > * it should be pure python > * fast and interactive 3D stuff > * needs to work out of the box on linux, mac os x, windows (without > compilation) We have long wanted limited 3D capability in matplotlib, and as you know we have some functionality in the axes3d classes but it has proven to be extremely slow, and somewhat buggy, and the original author has moved on to other things so it is mostly unsupported. We would be very excited if there was some way to incorporate your work using pyglet, which is very nice. matplotlib started out life as pure python, and for several release cycles remained that way. A that time, there were two backends, GTK and PS, so there is no reason in principle that matplotlib needs to have extension code. Over time, we have evolved a considerable amount of extension code, which Michael outlined for you, but it generally falls into two classes: * access 3rd party C/C++ (Agg, freetype and libpng) * make matplotlib go faster (image, transforms, other helpers) A big chunk of extension code was removed in Michael's recent refactoring of transforms, and it is possible and desirable to remove more. Eg, we should be able to replace ft2font with a ctypes wrapper, though I have never experimented with this. While I think reducing the amount of extension code is useful and desirable, the complete eradication of it is unlikely, and would result in a matplotlib with limited functionality. Michael mentioned a few of these areas, but contouring and image support make heavy use of extension code that would be difficult to do in python. Also, we depend very heavily numpy, so even if matplotlib were pure python, it would depend on numpy which is not. And that dependency is at the core of matplotlib. I tend to agree with Michael: our effort would be better spent identifying the areas that make compilation problematic than trying to remove all extension code. For the most part, these difficulties arise from depending on 3rd party C/C+ code at compile time (eg a GUI toolkit or libpng or freetype). I would love to find a way to remove all these compile time dependencies. > Another cool stuff in matplotlib is the pure python latex renderer > (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for > more info: Yes, the mathtext support in matplotlib is very nice, and Michael deserves the credit for taking from a package that works but has warts, to an extremely nice math layout engine using the Knuth algorithms. I'm sure others would like to use it without having to pull in all of matplotlib. With a ctypes freetype wrapper, it should be possible to build a free-standing mathtext. JDH ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
