Ok, I have some questions about what the protocol for patch submission should be, in terms of 'completeness' of the patch.
I have a patch for the quiver function that is half done... it has converted the arrows from patches to linecollections, and it will accept arbitrary X and Y coordinates for the arrow positions, as suggested by Rob. Unfortunetly, none of the color functionality is working. Partly this is because the color functionality of LineCollection is different from PolyCollection (which quiver originally used) and partly because I don't understand how matplotlib sets colors at all. Should I submit this half finished patch so that others can have a chance to improve the color function? Or should I not submit until I figure out how color works and fix the thing?
Furthermore, can LineCollection actually do all the things that quiver's old color commands demand of it? I don't see a place to set a colormap for a LineCollection, but as I said, I don't understand it very well.
Jordan
Jordan,
Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..."
My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interfering with getting the transforms right so that the arrows would look right, like text, regardless of how the axes are stretched or squished. Maybe the LineCollection makes this easier, but I am reasonably sure it can be done cleanly and well with PolyCollections also. (I am biased toward the PolyCollection approach because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's m_map; I will need something like this for basemap if it does not already exist.)
Eric
ยทยทยท
----- Original Message -----
From: Jordan Dawe <jdawe@...270...>
Date: Monday, May 29, 2006 7:18 pm
Subject: [matplotlib-devel] Quiver
To: matplotlib development list <matplotlib-devel@lists.sourceforge.net>
Ok, I have some questions about what the protocol for patch
submission
should be, in terms of 'completeness' of the patch.
I have a patch for the quiver function that is half done... it has
converted the arrows from patches to linecollections, and it will
accept
arbitrary X and Y coordinates for the arrow positions, as suggested
by
Rob. Unfortunetly, none of the color functionality is working.
Partly
this is because the color functionality of LineCollection is
different
from PolyCollection (which quiver originally used) and partly
because I
don't understand how matplotlib sets colors at all. Should I
submit
this half finished patch so that others can have a chance to
improve the
color function? Or should I not submit until I figure out how
color
works and fix the thing?
Furthermore, can LineCollection actually do all the things that
quiver's
old color commands demand of it? I don't see a place to set a
colormap
for a LineCollection, but as I said, I don't understand it very well.
Jordan
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and
Risk!Fully trained technicians. The highest number of Red Hat
certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-
us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Eric Firing wrote:
Jordan,
Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..."
My impression from the earlier posts on this topic was that part of the trouble was an attempt to be too clever and too automatic; this was interfering with getting the transforms right so that the arrows would look right, like text, regardless of how the axes are stretched or squished. Maybe the LineCollection makes this easier, but I am reasonably sure it can be done cleanly and well with PolyCollections also. (I am biased toward the PolyCollection approach because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's m_map; I will need something like this for basemap if it does not already exist.)
Eric
No, I am not sure we want to use LineCollection. I am using it because it is harder to see the distortions introduced by data coordinates when lines are used instead of polygons. I don't understand the transforms and I feel I have zero chance of getting a good looking plot in a reasonable length of time working with polygons. So I've been going the LineCollection way for two reasons: one, Gary's post with his line arrow seemed to indicate he was working in that direction as well (although it appears I was hasty to assume that, judging by his follow-up post), and two, because I figured I could get something going quickly and then build on it. So really, this isn't a transform issue anymore, because I've abandoned that idea as beyond my abilities.
If you all feel that turning quiver into line objects isn't a good idea, then there's not really much work I can do on it; the polygons work as well as they are going to as-is.
Also, a question: why use collection objects? The implimentation doesn't strike me as being much faster rendering wise, but maybe I'm wrong. Is it just so all the objects can be manipulated all at once by changing the state of the collection? Also, is there any particular reason the collections only accept verts or segments, instead of being able to just send it a patch or line object and have the collection object extract the relevant data?
Jordan