On 05/30/2013 08:21 PM, Michael Droettboom wrote: > 1) It's implemented in ctypes. I'm not much of a fan of ctypes, as it > has the potential to segfault in nasty ways if the API changes in any > way from what was expected (which would normally be caught at compile > time in a C extension). I'm also concerned about the overhead of > ctypes, given that there are already so many required optimizations in > the matplotlib freetype wrapper to make it fast enough. But I'm > willing to hold judgement on that until some measurements have been > made. 2) It's not Numpy-aware. For example, it loads image buffers > into regular Python lists. This really should use Numpy for speed. 3) > It exposes the fixed point numbers to Python as integers -- it should > really return all of these as floats -- the user shouldn't have to > know or remember which values are 16.16 and which are 24.8 etc. It > should just give floats. Double precision (with 52 bits in the > mantissa) is enough for any of these 32-bit fixed-point values. I > think that's just a remnant of older systems and needing to run on > hardware without an FPU that doesn't need to be brought forward into > the Python wrapper. 4) It should have another layer to handle the > decoding of SFNT tables in a consistent manner. I know the > sfnt-names.py example does this, but that should be built into the > library. There are certain places where hiding the details of the > underlying font file is a good thing -- and I think one of the reasons > freetype doesn't do this is the lack of a standard Unicode type in C. > We don't have that problem in Python. I think all of these are fixable > by adding another layer on top, with the exception of (1) of course. > Maybe it makes sense to build that intermediate layer, adapt > matplotlib to it, benchmark the ctypes issue, and if necessary > reimplement the core using C/API. Additionally, I just discovered that ctypes isn't available on Google App Engine, for obvious security reasons. That sort of, unfortunately, makes it a non-starter for matplotlib.
Wish that weren't the case, but I think Google App Engine support is an important thing to keep going... Mike ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
