matplotlib-devel Mailing List for matplotlib

On Dec 30, 2007 12:33 PM, Ondrej Certik <on...@ce...> 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

I'm off with family for the holidays, so my response will have to be somewhat 
brief. 
I'm excited about the ideas you bring up... I first heard about sympy at SciPy 
and was very impressed. Let's try to collaborate in any way possible. I know 
that "3D in matplotlib" already has some history of which I'm not aware, so I'll 
leave that for others to comment on.
As for the C++ dependencies, Agg is a pretty strong one. Yes, it is possible to 
do rendering with Gtk or Wx alone, but it's not very pretty (no-aa). Gtk/Cairo is 
a good high-quality combination, but it (at least currently) leaves out all the 
other GUI frameworks, and is not BSD-like licensed. The other important 
C/C++ requirement is matplotlib's interface to freetype (FT2Font). That would 
be really painful to reimplement in pure Python -- freetype is a complex and 
mature piece of software. In the trunk, there is a required framework for 
transformations, and in the "transforms branch" there is a framework for 
polycurve manipulations, both of which are required to do any plotting. Those 
would have a major performance penalty going to Python, and even 
notwithstanding, are non-trivial bits of code to reimplement. Beyond that, there 
are utilities for contours and images etc., which are reasonably optional but 
people use all the time. In short, there's a not of C/C++ in the core of 
matplotlib -- maybe the time would be better spent resolving any build issues 
that make portability difficult...? I'm not sure it's realistic to expect matplotlib to 
be pure Python at this point without losing a lot of features, but I agree it would 
be nice...
As for the mathtext Python math rendering engine, it isn't *really* pure Python. 
It relies on matplotlib's interface to Freetype. Ideally, it would be nice to have a 
general-purpose Python interface to freetype (I know the PyCairo folks are 
wanting such a thing), and then the mathtext engine could use that. 
Unfortunately, the existing freetype wrapper in matplotlib is very incomplete 
and pretty tied to matplotlib-specific ways of doing things. IMHO, you wouldn't 
really gain much by releasing FT2Font as a separate project unless it were 
generalized. I've sort of gone into a holding pattern, hoping someone else will 
release a Python freetype wrapper that matplotlib could use... Alternatively, the 
dependency on freetype could be removed by extracting and hardcoding all the 
font metrics from the math fonts into Python dictionaries etc. -- but then of 
course it would only work with a fixed set of fonts. This is what jsMath, (a 
pure-Javascript math rendering engine) does, for instance.
With the exception of that issue, removing the mathtext engine from matplotlib 
should be possible, and I think it's a great idea. There are some matplotlib-
specific bits mixed in there, but they should be reasonably straightforward to 
factor out. It already has support for rendering math to an in-memory image 
bitmap, which has been used for displaying math on GUI widgets, for example.
Anyway -- cool ideas. Let's keep up the discussion.
Cheers,
Mike