From: <jd...@us...> - 2007-07-19 02:40:18
|
Revision: 3569 http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3569&view=rev Author: jdh2358 Date: 2007-07-18 19:40:15 -0700 (Wed, 18 Jul 2007) Log Message: ----------- added design goals doc Modified Paths: -------------- trunk/matplotlib/mpl1/mpl1.py trunk/matplotlib/mpl1/mtraits.py Added Paths: ----------- trunk/matplotlib/mpl1/DESIGN_GOALS Added: trunk/matplotlib/mpl1/DESIGN_GOALS =================================================================== --- trunk/matplotlib/mpl1/DESIGN_GOALS (rev 0) +++ trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 02:40:15 UTC (rev 3569) @@ -0,0 +1,116 @@ +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 + Modified: trunk/matplotlib/mpl1/mpl1.py =================================================================== --- trunk/matplotlib/mpl1/mpl1.py 2007-07-18 21:52:01 UTC (rev 3568) +++ trunk/matplotlib/mpl1/mpl1.py 2007-07-19 02:40:15 UTC (rev 3569) @@ -1,3 +1,4 @@ +# see install instructions for enthrought traits2 in mtraits import enthought.traits.api as traits from matplotlib import agg @@ -395,7 +396,7 @@ y2 = 10*npy.exp(-x) line1 = line(x, y1, color='blue', linewidth=2.0) -line1.affine = coords1.affine +line1.sync_trait('affine', coords1) fig.add_path(line1) Modified: trunk/matplotlib/mpl1/mtraits.py =================================================================== --- trunk/matplotlib/mpl1/mtraits.py 2007-07-18 21:52:01 UTC (rev 3568) +++ trunk/matplotlib/mpl1/mtraits.py 2007-07-19 02:40:15 UTC (rev 3569) @@ -1,14 +1,19 @@ """ Install instructions for traits 2.0 + # blow away old enthought rm -rf ~/dev/lib/python2.4/site-packages/enthought.* - easy_install --install-dir=~/dev/lib/python2.4/site-packages --prefix=~/dev -f http://code.enthought.com/enstaller/eggs/source/unstable/ enthought.etsconfig enthought.util enthought.debug + # get easy_install, if necessary + wget http://peak.telecommunity.com/dist/ez_setup.py + sudo python sez_setup.py + sudo easy_install -f http://code.enthought.com/enstaller/eggs/source/unstable/ enthought.etsconfig enthought.util enthought.debug + svn co https://svn.enthought.com/svn/enthought/branches/enthought.traits_2.0 enthought_traits cd enthought_traits/ - python setup.py install --prefix=~/dev + sudo python setup.py install """ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |