On Fri, Jun 13, 2008 at 7:40 AM, Manuel Metz <[EMAIL PROTECTED]> wrote:
> Paul Novak had planed to work on scatter legend and I am also interested in > this, so we came up with a code fragment, but it doesn't do the job well. I > think a legend for scatter is something that is really needed for > matplotlib. The main problem is, that I got lost in all those transform > things - finally I felt like crazy ;-) > I think that's something that is also a bit "unfortunate" in matplotlib. > Basically, there are two different routines to draw markers: one is plot(), > and on is scatter(). Both do nearly the same thing, but use different code > bases. > It might be worth to think about reorganizing this ??? Having one function > that creates markers, and incorporating them from both, scatter() and > plot(), sounds like a good idea to me !? This is how I see it -- plot draws homogeneous markers. Knowing they are homogeneous allows us to do optimizations in the backend, like cacheing the rasterized marker and blitting it many places. This can radically speed up plots where there are many markers. scatter, on the hand, exists to draw heterogeneous markers, which vary either in size or in color or both. This is why I have always been lukewarm in adding auto-legend support -- which of the heterogeneous scatter symbols gets the legend entry? I n cases where you only vary the color or only vary the size, one could use the first polygon as a proxy for auto-legending. This wouldn't work all the time, but it might be good enough for folks who want auto-legends and others would still have the option of doing the legend polygon proxy trick. One way to make this easier would be for the polygon collections to provide a polygon_proxy method which returns a unit area patches.Polygon instance with properties set to correspond to the first polygon in the collection -- then the legend implementer could use it w/o worrying about all the different types of polygon collections and the odd sizing that may occur by simply taking the first element. But yes, to the extent that we can centralize the marker symbol -> path creation and reuse that between the line2d and poly collection code, that would be a good thing. One could then scale and translate the canonical polygons as needed for their respective uses. On the size as area usage in scatter -- I have found this counter-intuitive from day 1, and I wrote the damned thing, but as I noted we inherited this from matlab and a lot of code is built around it, so we are probably stuck with it. If you think it is sufficiently irksome, you can add a kwarg to scatter along the lines of def scatter(..., sizearea=True) where if sizearea is False we treat the size as a linear dimension. This could also be an rc param so people could set the defaults to behave in a more intuitive way w/o breaking the old code. JDH ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
