A reimplementation of the quiver command has been committed to svn. It is temporarily accessible as "quiver2" so as not to interfere with the original quiver, and in examples there is a quiver2_demo.py. The API differs from that of the original quiver. See the docstring for details. Since the earlier version that I sent out as a diff, I have removed the "C" kwarg (unnecessary, given the function signature) and added the "minlength" kwarg; if the rendered arrow is less than this length in units of the shaft width, then it is replaced with a hexagon of this diameter. Also, the dpi bug that John found is fixed.
Some time before the next release I would like to replace the present quiver with quiver2. If necessary I can use the same trick as for colorbar, in which the default is the new version, but the presence of a kwarg exclusive to the old version triggers use of the old version with a deprecation warning. I would like to be able to establish a schedule for actually removing such deprecated code, however.
Suggestions for improvements in the API or other aspects are welcome.
On my todo list are a "key" method to draw a labeled scale arrow, and an ellipse-drawing capability.
The "scatter" command is quite similar and, like the proposed "ellipses", could take advantage of code presently in the Quiver class, so I will consider doing such a consolidation, using a base class or a mixin to factor out as much common functionality as possible.
I have looked briefly at basemap. It looks like quiver2 will fit in OK with small changes; a bit more work might be needed to support some of the scaling options in quiver2. In any case, whenever quiver2 does replace quiver I want to make sure that basemap is ready so that the new quiver works well with it; for my own work, velocity vectors on maps are central.
Eric
They look great! I would think a DeprecationWarning when you detect
the old usage would suffice for 1 major release cycle, hence all of
0.88.
Thanks,
Charlie
···
On 6/9/06, Eric Firing <efiring@...229...> wrote:
A reimplementation of the quiver command has been committed to svn. It
is temporarily accessible as "quiver2" so as not to interfere with the
original quiver, and in examples there is a quiver2_demo.py. The API
differs from that of the original quiver. See the docstring for
details. Since the earlier version that I sent out as a diff, I have
removed the "C" kwarg (unnecessary, given the function signature) and
added the "minlength" kwarg; if the rendered arrow is less than this
length in units of the shaft width, then it is replaced with a hexagon
of this diameter. Also, the dpi bug that John found is fixed.
Some time before the next release I would like to replace the present
quiver with quiver2. If necessary I can use the same trick as for
colorbar, in which the default is the new version, but the presence of a
kwarg exclusive to the old version triggers use of the old version with
a deprecation warning. I would like to be able to establish a schedule
for actually removing such deprecated code, however.
Suggestions for improvements in the API or other aspects are welcome.
On my todo list are a "key" method to draw a labeled scale arrow, and an
ellipse-drawing capability.
The "scatter" command is quite similar and, like the proposed
"ellipses", could take advantage of code presently in the Quiver class,
so I will consider doing such a consolidation, using a base class or a
mixin to factor out as much common functionality as possible.
I have looked briefly at basemap. It looks like quiver2 will fit in OK
with small changes; a bit more work might be needed to support some of
the scaling options in quiver2. In any case, whenever quiver2 does
replace quiver I want to make sure that basemap is ready so that the new
quiver works well with it; for my own work, velocity vectors on maps are
central.
Eric
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Hi,
an option for quiver to quickly draw thousands of simple monocolor
arrows each constructed from e.g. 3 line segments would be useful for
someone(like me) that uses matplotlib
for browsing vector plots of large fields (e.g. 800x600). currently
this is not practical
with any of the quiver variants, as it takes minutes to render. I
already use linecollections
to draw high res coastlines, so a faster quiver should be feasible.
another optimization could be perhaps be to arrange for numpy arrays
to be passed directly to the drawing methods instead of the all the
zipping and loops that currently are necessary?
otherwise, quiver2 looks very good for final plots - good work!
Helge
···
On 6/9/06, Eric Firing <efiring@...229...> wrote:
Suggestions for improvements in the API or other aspects are welcome.
Helge,
Helge Avlesen wrote:
Suggestions for improvements in the API or other aspects are welcome.
Hi,
an option for quiver to quickly draw thousands of simple monocolor
arrows each constructed from e.g. 3 line segments would be useful for
someone(like me) that uses matplotlib
for browsing vector plots of large fields (e.g. 800x600). currently
this is not practical
with any of the quiver variants, as it takes minutes to render. I
already use linecollections
to draw high res coastlines, so a faster quiver should be feasible.
I have made some changes to facilitate this, but I have not tried to implement it yet. It should be possible with only a little bit more code than is in quiver.py at present, but it may require figuring out a trick or two. I don't want to work on it quite yet, but it does seem like a good idea--provided rendering LineCollections really is much faster than rendering PolyCollections.
another optimization could be perhaps be to arrange for numpy arrays
to be passed directly to the drawing methods instead of the all the
zipping and loops that currently are necessary?
Quite some time ago I asked John about this, and the answer was that all this conversion overhead is probably not a large part of the total plotting time, so optimizing it may not be worth the trouble. But I agree--it would seem much more natural to pass X and Y arrays around than to have to zip them into sequences of (x,y) tuples.
Eric
···
On 6/9/06, Eric Firing <efiring@...229...> wrote: