Perry, John, Progress!
Cool!
> I found that the problem I was having with PolyCollection
> was this: the vertices argument must be a sequence (list or
> tuple) of tuples of tuples--if one gives it a list of
> *lists* of tuples, one gets
> [first part of trace omitted] File
> "/usr/lib/python2.3/site-packages/matplotlib/collections.py",
> line 205, in draw self._offsets, self._transOffset)
> TypeError: CXX: type error
> (The line number was smaller before I put in some debugging
> print statements.)
> I think this fussiness qualifies as a bug; the docstring for
> PolyCollection says vertices can be a sequence of sequences
> of tuples. I don't know what the right way to fix it is,
> however, so I am working around it.
Fair enough -- I just fixed all the agg collection drawing routines to
work with the sequence API and not require tuples. Glad to see you're
making progress -- poly contouring is something I'd like to see added.
> Having solved that problem, I am getting more optimistic
> about being able to come up with a usable filled contour
> capability fairly quickly. Still no promises, though.
Great -- be mindful of the contourf matlab docstrings. Strict
adherence is not required, but it is nice to be compatible where
possible.
> All this brings to mind a question that has puzzled me for a
> long time: why does matplotlib internally use sequences of
> (x,y) tuples instead of numerix arrays--either a 2-D array,
> or a pair (or tuple) of 1-D arrays? I would think that
> running all plotted numbers through the conversion from
> arrays to Python tuples, and then from there into the native
> data types for each backend, would incur a big performance
> penalty when plotting large numbers of points. Not that I
> am suggesting a redesign--I am just curious.
Historical and other reasons. The historical part is that this part
of the code was written before Todd had solved the numeric/numarray
API compatibility problem for matplotlib. These are now solved, 've
been slowly adding some numerix code to backend agg, most recently in
0.72. I don't think it would make a lot of difference for
collections. In the first place, you'd have to create all these lists
of numarray lists, since the collection is by definition a list of
disconnected lines. In the second place, there is a fair amount going
on in the inner loop that I think would offset the gains you get from
using numeric. In draw_lines, where the x,y access is a major part of
the inner loop, I do use numerix.
The backend API is moving to a path drawing model, which may obviate
the need for specialized collection drawing methods. The collection
interface would remain unchanged, but we might get away w/o having
special methods to draw them.
JDH