Menu
▾
▴
matplotlib-checkins
|
From: <jd...@us...> - 2007-07-19 03:00:23
|
Revision: 3570
http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3570&view=rev
Author: jdh2358
Date: 2007-07-18 20:00:21 -0700 (Wed, 18 Jul 2007)
Log Message:
-----------
minor revisions to design goals
Modified Paths:
--------------
trunk/matplotlib/mpl1/DESIGN_GOALS
Modified: trunk/matplotlib/mpl1/DESIGN_GOALS
===================================================================
--- trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 02:40:15 UTC (rev 3569)
+++ trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:00:21 UTC (rev 3570)
@@ -19,45 +19,50 @@
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
+there are three 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?
+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
+Have just a few, fairly rich obects, that the backends need to
+understand. Clear candidates are a Path, Text and Image, but despite
+some similar names, don't confuse these with the current matplotlib
+Artists by the same name, which are considerably higher level than
+what I'm thinking of here. 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?
+In matplotlib, the plot functions are axes methods and I think there
+is consensus that 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.
+Line, each of which manage a Path object under the hood? Probably,
+for user convenience and general compability with matplotlib. 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.
+carefully about how this should be handled. Paul may be a good
+candidate for this, since he has been working on picking.
= 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
+small a nitch of the python world to base our project 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
@@ -67,33 +72,40 @@
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.
+outside MPL, eg in a toolkit, if we need it. This means someone needs
+to figure out how to get tk talking to a python buffer or numpy array.
+Maintaining the GUI extension code across platforms is an unending
+headache.
= 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.
+the ground up. Without the UI stuff, they add plenty to make them
+worthwhile, especially the validation and notification features. With
+the UI (wx only) , they are a major win for GUI developers. Compare
+the logic for sharing an x-axis in matplotlib transforms with sharex
+with the approach used in mpl1.py with synch-ed affines.
= 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
+The whole conception of the Axes needs to be rethought, in light of
+the fact that we need to support multiple axis objects on one Axes.
+The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
+and we hack two y-axis support with some transform shenanigans via
+twinx, but the approach is not generalizable and is unweildy.
+
+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.
+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.
+I think we need to be prepared to break the hell out of matplotlib.
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
+work unchanged -- that is the beauty of pylab - though API calls on
+return obects will probably be badly broken. 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)
@@ -101,16 +113,32 @@
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
+rightly consider this to be the mpl2 proposal, and keep releasing
matplotlib ehancements to 1.0 and beyond w/o signfificant breakage.
It's a nominal difference so I don't really have a preference.
+Or we could forget all this wild speculation and resume our normally
+scheduled lives.
+
= 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
+It is a good idea for an enterprising developer to take a careful look
+at tghe current Chaco and Kiva to see if we can further integrate with
+them. I am gun shy because they seem formiddable and complex, and one
+of my major goals here is to streamline and simplify, but they are
+incredible pieces of work and we need to carefully consider them,
+especially as we integrate other parts of the enthought suite into our
+core, eg traits, increasing the possibility of synergies.
+
+= unit handling, custom object types =
+
+There is a legitimate need to be able to feed custom objects into
+matplotlib. Recent versions of matplotlib support this with a unit
+registry. A clear use case is plotting with native datetime objects,
+which is supported in the latest release of matplotlib via the unit
+handling, which should probably be called "custom object handling and
+conversion". This is a deep and complicaed subect, involving
+questions of where the original data live, how they are converted to
+useful types (arrays of floats) etc. It's worth thinking about as we
+discuss redesign issues.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jd...@us...> - 2007-07-19 03:16:55
|
Revision: 3571
http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3571&view=rev
Author: jdh2358
Date: 2007-07-18 20:16:53 -0700 (Wed, 18 Jul 2007)
Log Message:
-----------
minor revisions to design goals
Modified Paths:
--------------
trunk/matplotlib/mpl1/DESIGN_GOALS
Modified: trunk/matplotlib/mpl1/DESIGN_GOALS
===================================================================
--- trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:00:21 UTC (rev 3570)
+++ trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:16:53 UTC (rev 3571)
@@ -2,56 +2,65 @@
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?)
+would get a good sketch working, and then organize a spint (3-4 days?)
for late August, where we try get as far as possible to making this
viable.
-= data copying =
+= 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
+Push the data to the backend only once, or only when required. Update
+the transforms in 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
+move the data around on every draw. Eg see how mpl1.py handles pusing
+the paths when the renderer is set (Figure.set_renderer) but on draw
+commands (Figure.draw) only pushes the current affine.
+= Transformations =
-= 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 three 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
+implementation assumes one nonlinear transformation, which happens at
+a high layer, and all transformations after that are affines. In the
+mpl1 draft, there are three affines: the transformation from view
+limits -> axes units (AxesCoords.affineview), the transformation from
+axes units to normalized figure units (AxesCoords.affineaxes), and the
+transformation from normalized figure units to display
+(Renderer.affine)
Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
-= objects that talk to the backend "primitives" =
+= Objects that talk to the backend "primitives" =
Have just a few, fairly rich obects, that the backends need to
understand. Clear candidates are a Path, Text and Image, but despite
-some similar names, don't confuse these with the current matplotlib
-Artists by the same name, which are considerably higher level than
-what I'm thinking of here. 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".
+similar names, don't confuse these with the current matplotlib Artists
+by the same name, which are considerably higher level than what I'm
+thinking of here. 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? =
+= Where do the plot functions live? =
In matplotlib, the plot functions are axes methods and I think there
is consensus that this is a poor design. Where should these live,
what should they create, etc?
-= how much of an intermediate artist layer do we need =
+= 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,
for user convenience and general compability with matplotlib. By
using traits properly here, these will be thin interfaces around one
-of our primitives.
+of our primitives. I think the whole collections module is poorly
+designed, and should be chucked wholesale, if favor of faster, more
+elegant, optimizations and special cases. Just having the right Path
+object will reduce the need for many of these, eg LineCollection,
+PolygonCollection, etc... Also, everything should be numpy enabled,
+and the list of python tuples approach that many of the collections
+take should be shed.
-= z-ordering, containers, etc =
+= 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,
@@ -59,7 +68,7 @@
carefully about how this should be handled. Paul may be a good
candidate for this, since he has been working on picking.
-= extension code =
+= 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 project on. SWIG is
@@ -67,17 +76,18 @@
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.
+enhance the SWIG agg wrapper, we can also do images through there.
+Having a fully featured python exposed 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 needs
-to figure out how to get tk talking to a python buffer or numpy array.
-Maintaining the GUI extension code across platforms is an unending
-headache.
+outside MPL if at all, eg in a toolkit, if we need it. This means
+someone needs to figure out how to get tk talking to a python buffer
+object or numpy array. Maintaining the GUI extension code across
+platforms is an unending headache.
-= traits =
+= Traits =
I think we should make a major committment to traits and use them from
the ground up. Without the UI stuff, they add plenty to make them
@@ -86,29 +96,36 @@
the logic for sharing an x-axis in matplotlib transforms with sharex
with the approach used in mpl1.py with synch-ed affines.
-= axis handling =
+= Axis handling =
The whole conception of the Axes needs to be rethought, in light of
the fact that we need to support multiple axis objects on one Axes.
The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
and we hack two y-axis support with some transform shenanigans via
-twinx, but the approach is not generalizable and is unweildy.
+twinx, but the approach is not generalizable and is unwieldy.
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.
+gridline, ticklabel, etc, and this is mind-numbingsly slow. I have
+some proto-type axis implementations that draw all the ticks with a
+single path using repeated MOVETO and LINETO, for example, which will
+be incomparably faster, than using a separate object from each tick.
-= breakage =
+= Breakage =
I think we need to be prepared to break the hell out of matplotlib.
The API will basically be a total rewrite. pylab will still mostly
work unchanged -- that is the beauty of pylab - though API calls on
-return obects will probably be badly broken. 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)
+return obects will probably be badly broken. We can mitigate this
+pain if we desire with clever wrapper objects, but once you start
+calling methods on return objects, you oin the community of power
+users, and this is the community I'm most willing to inconvenience
+with breakage. 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 initially (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
@@ -120,10 +137,10 @@
Or we could forget all this wild speculation and resume our normally
scheduled lives.
-= chaco and kiva =
+= Chaco and Kiva =
It is a good idea for an enterprising developer to take a careful look
-at tghe current Chaco and Kiva to see if we can further integrate with
+at the current Chaco and Kiva to see if we can further integrate with
them. I am gun shy because they seem formiddable and complex, and one
of my major goals here is to streamline and simplify, but they are
incredible pieces of work and we need to carefully consider them,
@@ -131,14 +148,14 @@
core, eg traits, increasing the possibility of synergies.
-= unit handling, custom object types =
+= Unit handling, custom object types =
There is a legitimate need to be able to feed custom objects into
matplotlib. Recent versions of matplotlib support this with a unit
-registry. A clear use case is plotting with native datetime objects,
-which is supported in the latest release of matplotlib via the unit
-handling, which should probably be called "custom object handling and
-conversion". This is a deep and complicaed subect, involving
-questions of where the original data live, how they are converted to
-useful types (arrays of floats) etc. It's worth thinking about as we
-discuss redesign issues.
+registry in the "units" module. A clear use case is plotting with
+native datetime objects, which is supported in the latest release of
+matplotlib via the unit handling, which should probably be called
+"custom object handling and conversion". This is a deep and
+complictaed subject, involving questions of where the original data
+live, how they are converted to useful types (arrays of floats) etc.
+It's worth thinking about as we discuss redesign issues.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jd...@us...> - 2007-07-19 03:35:22
|
Revision: 3572
http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3572&view=rev
Author: jdh2358
Date: 2007-07-18 20:35:18 -0700 (Wed, 18 Jul 2007)
Log Message:
-----------
minor revisions to design goals
Modified Paths:
--------------
trunk/matplotlib/mpl1/DESIGN_GOALS
Modified: trunk/matplotlib/mpl1/DESIGN_GOALS
===================================================================
--- trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:16:53 UTC (rev 3571)
+++ trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:35:18 UTC (rev 3572)
@@ -11,7 +11,7 @@
Push the data to the backend only once, or only when required. Update
the transforms in 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. Eg see how mpl1.py handles pusing
+move the data around on every draw. Eg, see how mpl1.py handles pusing
the paths when the renderer is set (Figure.set_renderer) but on draw
commands (Figure.draw) only pushes the current affine.
@@ -28,17 +28,22 @@
Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
+How do transformations (linear and nonlinear) play wtih Axis features
+(ticking and gridding). The ideal is an framework in which ticking,
+gridding and labeling work intelligently with arbitrary
+transformations. What is the proper transformation API?
+
= Objects that talk to the backend "primitives" =
Have just a few, fairly rich obects, that the backends need to
understand. Clear candidates are a Path, Text and Image, but despite
-similar names, don't confuse these with the current matplotlib Artists
-by the same name, which are considerably higher level than what I'm
-thinking of here. 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".
+their similar names, don't confuse these with the current matplotlib
+eponymous matplotlib Artists, which are considerably higher level than
+what I'm thinking of here. Each of these will carry their metadata,
+eg a path will carry its stroke color, facecolor, linewidth, etc...,
+and Text will carry its font size, color, etc.... We may need some
+optimizations down the road, but we should start small. For now,
+let's call these objects "primitives".
= Where do the plot functions live? =
@@ -51,81 +56,85 @@
Do we want to create high level objects like Circle, Rectangle and
Line, each of which manage a Path object under the hood? Probably,
for user convenience and general compability with matplotlib. By
-using traits properly here, these will be thin interfaces around one
-of our primitives. I think the whole collections module is poorly
-designed, and should be chucked wholesale, if favor of faster, more
-elegant, optimizations and special cases. Just having the right Path
-object will reduce the need for many of these, eg LineCollection,
+using traits properly here, many current matplotlib Arists will be
+thin interfaces around one oer more primitives.
+
+I think the whole matplotlib.collections module is poorly designed,
+and should be chucked wholesale, in favor of faster, more elegant,
+optimizations and special cases. Just having the right Path object
+will reduce the need for many of these, eg LineCollection,
PolygonCollection, etc... Also, everything should be numpy enabled,
-and the list of python tuples approach that many of the collections
-take should be shed.
+and the sequence-of-python-tuples approach that many of the
+collections take should be dropped.
= 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 may be a good
-candidate for this, since he has been working on picking.
+Peter has been doing a lot of nice work on z-order and layers for
+chaco, stuff that looks really useful for picking, interaction, etc...
+We should look at this approach, and think carefully about how this
+should be handled. Paul may be a good candidate for this, since he
+has been working recently on picking.
= 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 project on. SWIG is
+small a nitch in the python world to base our project 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 there.
-Having a fully featured python exposed agg wrapper will be a plus.
-But with the agg license change, I'm open to discussion of
-alternatives.
+necessary, to get 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 there, getting rid of
+_image.cpp. Having a fully featured, python-exposed agg wrapper will
+be a plus in mpl and beyond. But with the agg license change, I'm
+open to discussion of other approaches.
I want to do away with *all* GUI extension code. This should live
-outside MPL if at all, eg in a toolkit, if we need it. This means
-someone needs to figure out how to get tk talking to a python buffer
-object or numpy array. Maintaining the GUI extension code across
-platforms is an unending headache.
+outside MPL if at all, eg in a toolkit if we need it. This means
+someone needs to figure out how to get TkInter talking to a python
+buffer object or a numpy array. Maintaining the GUI extension code
+across platforms is an unending headache.
= Traits =
I think we should make a major committment to traits and use them from
-the ground up. Without the UI stuff, they add plenty to make them
-worthwhile, especially the validation and notification features. With
-the UI (wx only) , they are a major win for GUI developers. Compare
-the logic for sharing an x-axis in matplotlib transforms with sharex
-with the approach used in mpl1.py with synch-ed affines.
+the ground up. Even without the UI stuff, they add plenty to make
+them worthwhile, especially the validation and notification features.
+With the UI (wx only) , they are a major win for many GUI developers.
+Compare the logic for sharing an x-axis using matplotlib transforms
+with Axes.sharex with the approach used in mpl1.py with sync_trait-ed
+affines.
= Axis handling =
-The whole conception of the Axes needs to be rethought, in light of
-the fact that we need to support multiple axis objects on one Axes.
-The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
-and we hack two y-axis support with some transform shenanigans via
-twinx, but the approach is not generalizable and is unwieldy.
+The whole concept of the Axes needs to be rethought, in light of the
+fact that we need to support multiple axis objects on one Axes. The
+matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes, and we
+hack two y-axis support (examples/two_scales.py) with some transform
+shenanigans via twinx, but the approach is not generalizable and is
+unwieldy.
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. I have
-some proto-type axis implementations that draw all the ticks with a
-single path using repeated MOVETO and LINETO, for example, which will
-be incomparably faster, than using a separate object from each tick.
+with individual artists or primitives. They also need to be *much*
+faster. matplotlib uses Artists for each tick, tickline, gridline,
+ticklabel, etc, and this is mind-numbingly slow. I have a prototype
+axis implementations that draws the ticks with a single path using
+repeated MOVETO and LINETO, for example, which will be incomparably
+faster than using a separate object for each tick.
= Breakage =
I think we need to be prepared to break the hell out of matplotlib.
The API will basically be a total rewrite. pylab will still mostly
-work unchanged -- that is the beauty of pylab - though API calls on
-return obects will probably be badly broken. We can mitigate this
-pain if we desire with clever wrapper objects, but once you start
-calling methods on return objects, you oin the community of power
-users, and this is the community I'm most willing to inconvenience
-with breakage. 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 initially (eg until a
-CXX free ft2font is available)
+work unchanged -- that is the beauty of pylab -- though API calls on
+return obects may be badly broken. We can mitigate this pain if we
+desire with clever wrapper objects, but once you start calling methods
+on return objects, you join the community of power users, and this is
+the community I'm most willing to inconvenience with breakage. 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 initially, 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
@@ -153,9 +162,9 @@
There is a legitimate need to be able to feed custom objects into
matplotlib. Recent versions of matplotlib support this with a unit
registry in the "units" module. A clear use case is plotting with
-native datetime objects, which is supported in the latest release of
-matplotlib via the unit handling, which should probably be called
-"custom object handling and conversion". This is a deep and
-complictaed subject, involving questions of where the original data
-live, how they are converted to useful types (arrays of floats) etc.
-It's worth thinking about as we discuss redesign issues.
+native datetime objects, which is supported in 0.90 via the unit
+handling, which should probably be called "custom object handling and
+conversion". This is a deep and complicated subject, involving
+questions of where the original data live, how they are converted to
+useful types (arrays of floats) etc. It's worth thinking this about
+as we discuss redesign issues.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jd...@us...> - 2007-07-19 03:53:39
|
Revision: 3573
http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3573&view=rev
Author: jdh2358
Date: 2007-07-18 20:53:37 -0700 (Wed, 18 Jul 2007)
Log Message:
-----------
minor revisions to design goals
Modified Paths:
--------------
trunk/matplotlib/mpl1/DESIGN_GOALS
Modified: trunk/matplotlib/mpl1/DESIGN_GOALS
===================================================================
--- trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:35:18 UTC (rev 3572)
+++ trunk/matplotlib/mpl1/DESIGN_GOALS 2007-07-19 03:53:37 UTC (rev 3573)
@@ -28,28 +28,33 @@
Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
-How do transformations (linear and nonlinear) play wtih Axis features
-(ticking and gridding). The ideal is an framework in which ticking,
-gridding and labeling work intelligently with arbitrary
-transformations. What is the proper transformation API?
+How do transformations (linear and nonlinear) play with Axis features
+(ticking and gridding). The ideal is a framework in which ticking,
+gridding and labeling work intelligently with arbitrary, user
+supplied, transformations. What is the proper transformation API?
= Objects that talk to the backend "primitives" =
Have just a few, fairly rich obects, that the backends need to
understand. Clear candidates are a Path, Text and Image, but despite
-their similar names, don't confuse these with the current matplotlib
-eponymous matplotlib Artists, which are considerably higher level than
-what I'm thinking of here. Each of these will carry their metadata,
-eg a path will carry its stroke color, facecolor, linewidth, etc...,
-and Text will carry its font size, color, etc.... We may need some
-optimizations down the road, but we should start small. For now,
-let's call these objects "primitives".
+their names, don't confuse these with the eponymous matplotlib
+matplotlib Artists, which are higher level than what I'm thinking of
+here (eg matplotlib.text.Text does *a lot* of layout, and this would
+be offloaded ot the backend in this conception of the Text primitive).
+Each of these will carry their metadata, eg a path will carry its
+stroke color, facecolor, linewidth, etc..., and Text will carry its
+font size, color, etc.... We may need some optimizations down the
+road, but we should start small. For now, let's call these objects
+"primitives".
+This approach requires the backends to be smarter, but they have to
+handle fewer entities.
+
= Where do the plot functions live? =
-In matplotlib, the plot functions are axes methods and I think there
-is consensus that this is a poor design. Where should these live,
-what should they create, etc?
+In matplotlib, the plot functions are matplotlib.axes.Axes methods and
+I think there is consensus that this is a poor design. Where should
+these live, what should they create, etc?
= How much of an intermediate artist layer do we need? =
@@ -57,7 +62,7 @@
Line, each of which manage a Path object under the hood? Probably,
for user convenience and general compability with matplotlib. By
using traits properly here, many current matplotlib Arists will be
-thin interfaces around one oer more primitives.
+thin interfaces around one or more primitives.
I think the whole matplotlib.collections module is poorly designed,
and should be chucked wholesale, in favor of faster, more elegant,
@@ -65,7 +70,8 @@
will reduce the need for many of these, eg LineCollection,
PolygonCollection, etc... Also, everything should be numpy enabled,
and the sequence-of-python-tuples approach that many of the
-collections take should be dropped.
+collections take should be dropped. Obviously some of the more useful
+things there, like quad meshes, need to be ported and retained.
= Z-ordering, containers, etc =
@@ -73,7 +79,7 @@
chaco, stuff that looks really useful for picking, interaction, etc...
We should look at this approach, and think carefully about how this
should be handled. Paul may be a good candidate for this, since he
-has been working recently on picking.
+has been working recently on the picking API.
= Extension code =
@@ -88,6 +94,10 @@
be a plus in mpl and beyond. But with the agg license change, I'm
open to discussion of other approaches.
+The major missing piece in ft2font, which is a pretty elaborate CXX
+module. Michael may want to consider alternatives, including looking
+at the agg support for freetype, and the kiva/chaco approach.
+
I want to do away with *all* GUI extension code. This should live
outside MPL if at all, eg in a toolkit if we need it. This means
someone needs to figure out how to get TkInter talking to a python
@@ -106,12 +116,12 @@
= Axis handling =
-The whole concept of the Axes needs to be rethought, in light of the
-fact that we need to support multiple axis objects on one Axes. The
-matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes, and we
-hack two y-axis support (examples/two_scales.py) with some transform
-shenanigans via twinx, but the approach is not generalizable and is
-unwieldy.
+The whole concept of the Axes object needs to be rethought, in light
+of the fact that we need to support multiple axis objects on one Axes.
+The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
+and we hack two y-axis support (examples/two_scales.py) with some
+transform shenanigans via twinx and multiple Axes where one is hidden,
+but the approach is not scalable and is unwieldy.
This will require a fair amount of thought, but we should aim for
supporting an arbitrary number of axis obects, presumably associated
@@ -122,19 +132,22 @@
repeated MOVETO and LINETO, for example, which will be incomparably
faster than using a separate object for each tick.
-= Breakage =
+The other important featiure for axis support is that, for the most
+part, they should be arbitrarily placeable (eg a "detached" axis).
+= Breakage =
+
I think we need to be prepared to break the hell out of matplotlib.
-The API will basically be a total rewrite. pylab will still mostly
-work unchanged -- that is the beauty of pylab -- though API calls on
-return obects may be badly broken. We can mitigate this pain if we
-desire with clever wrapper objects, but once you start calling methods
-on return objects, you join the community of power users, and this is
-the community I'm most willing to inconvenience with breakage. 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 initially, eg until a CXX free ft2font is
-available.
+The API will basically be a significant rewrite. pylab will still
+mostly work unchanged -- that is the beauty of pylab -- though API
+calls on return objects may be badly broken. We can mitigate this pain
+if we desire with clever wrapper objects, but once you start calling
+methods on return objects, you join the community of power users, and
+this is the community I'm most willing to inconvenience with breakage.
+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 initially, 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
@@ -162,9 +175,9 @@
There is a legitimate need to be able to feed custom objects into
matplotlib. Recent versions of matplotlib support this with a unit
registry in the "units" module. A clear use case is plotting with
-native datetime objects, which is supported in 0.90 via the unit
-handling, which should probably be called "custom object handling and
-conversion". This is a deep and complicated subject, involving
+native python datetime objects, which is supported in 0.90 via the
+unit handling, which should probably be called "custom object handling
+and conversion". This is a deep and complicated subject, involving
questions of where the original data live, how they are converted to
useful types (arrays of floats) etc. It's worth thinking this about
as we discuss redesign issues.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X