Here are some of the things I would like to accomplish with mpl1. Any

and all of this is open to discussion. What I present below is pretty

ambitious, so if there is support, we will need significant

contributions from several developers for several months. Ideally, we

would get a good sketch working, and then organize a spint (4 days?)

for late August, where we try get as far as possible to making this

viable.

= data copying =

Push the data to the backend only once, or only when required. update

the transforms to the backend, but do not push transformed data on

every draw. This is potentially a major win, because we currently

move the data around on every draw

= transformations =

Support a normal transformation architecture. The current draft

implmentation assumes one nonlinear transformation, which happens at a

high layer, and all transformations after that are affines. Currently

there are two affines: the transformation from view limits -> axes

units, the transformation from axes units to normalized figure untis,

and the transformation from normalized figure units to display

do we want to use 3x3 or 4x4 to leave the door open for 3D developers?

= objects that talk to the backend "primitives" =

Have just a few, fairly rich obects the backends need to understand.

clear candidates are a Path, Text and Image. Each of these will carry

their metadata, eg a path will carry its stroke color, facecolor,

linewidth, etc.. Text will carry its font size, color, etc. We may

need some optimizations down the road, but start small. For now,

let's call these objects primitives

= where do the plot functions live? =

In matplotlib, the plot functions are axes methods and this is a poor

design. Where should these live, what should they create, etc?

= how much of an intermediate artist layer do we need =

Do we want to create high level objects like Circle, Rectangle and

Line, each of which manage a Path object under the hood? Probably.

By using traits properly here, these will be thin interfaces around

one of our primitives.

= z-ordering, containers, etc =

Peter has been doing a lot of nice work on z-order and layers and

stuff like that for chaco, stuff that looks really useful for picking,

interactive, etc... We should look at their approach, and think

carefully about how this should be handled. Paul is a good candidate

for this.

= extension code =

I would like to shed all of the CXX extension code -- it is just too

small a nitch of the python world to base our proect on. SWIG is

pretty clearly the right choice. mpl1 will use numpy for

transformations with some carefully chosen extension code where

necessary, so this gets rid of _transforms.cpp. I also plan to use

the SWIG agg wrapper, so this gets rid of _backend_agg. If we can

enhance the SWIG agg wrapper, we can also do images through here.

Having a fully featured python agg wrapper will be a plus. But with

the agg license change, I'm open to discussion of alternatives.

I want to do away with *all* GUI extension code. This should live

outside MPL, eg in a toolkit, if we need it. This means someone

(Michael is probably a good choice) needs to figure out how to get tk

talking to a python buffer or numpy array. Maintaining the GUI

extension code is a drag.

= traits =

I think we should make a major committment to traits and use them from

the ground up. w/o the UI stuff, they add plenty to make them

worthwhile. With the UI (wx only) , they are a major win for GUI

developers.

= axis handling =

The whole conception of the Axes needs to be reworked, in light of the

fact that we need to support multiple axis objects on one Axes. This

will require a fair amount of thought, but we should aim for

supporting an arbitrary number of axis obects, presumably associated

with individual artists or primitives, on each Axes. They also need

to be *much* faster. matplotlib uses Artists for each tick, tickline,

gridline, ticklabel, etc, and this is mind-numbingsly slow.

= breakage =

I think we need to be prepared to break the hell out of this thing.

The API will basically be a total rewrite. pylab will still mostly

work unchanged -- that is the beauty of pylab. We'll probably want to

install into a new namespace, eg mpl, and envision both matplotlib and

mpl co-existing for some time. In fact, mpl might depend on

matplotlib for a while (eg until a CXX free ft2font is available)

We should expect to be supporting and using matplotlib for a long

time, since the proposals discussed here imply that it will be a long

wait until mpl1 is feature complete with matplotlib. In fact, we could

rightly consider this to be the mpl2 proposal, and keep releaseing

matplotlib ehancements to 1.0 and beyond w/o signfificant breakage.

It's a nominal difference so I don't really have a preference.

= chaco and kiva =

This is probably a good idea for an enterprising developer to take a

careful look at Chaco and Kiva to see if we can integrate with them.

I am gunshy because they seem formiddable and complex, and one of my

maor goals here is to streamline and simplify, but they are incredible

pieces of work and we need to consider them, especially if we

integrate other parts of the enthought suite into our core, eg traits