On 7/20/07, Eric Firing <[EMAIL PROTECTED]> wrote: > ngs up the larger question of the major > redesign that is underway, and how to make sure we don't lose the > benefit of wonderful speedups like quadmesh. How hard would it be to > translate it to use the swig-wrapped version of agg rather than > accessing agg directly via the present pycxx _backend_agg.cpp? And how > much performance do you think would be lost? Alternatively, is there a > better way to put the fast rendering capability in a smaller piece of > extension code that can be used in the new framework and that would not > rely on pycxx? E.g., a small swiggable chunk?
One can fairly easily add custom extension code into the SWIG wrappers themselves. A single example is swig/agg_buffer.h, a small C++ class I added to expose the underlying image buffer to python. We would definitely port over stuff like quadmesh, where the hard part is not in the python wrapper interface, but in the code and algorithm itself, which should port fairly easily. JDH 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
