Menu
▾
▴
[Matplotlib-checkins] SF.net SVN: matplotlib: [3569] trunk/matplotlib/mpl1
|
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.
|
