Eric Firing wrote: > Mike, > > Thank you for once again blasting out such an array of improvements. > Regarding implementation and API details, such as what should go in > imshow versus pcolor versus something with another name, I would like to > review the situation (and your branch) and come up with a > recommendation, but I can't do it immediately. I can have something > waiting for you on Monday morning, however.
Hey, no rush. I understand not everyone has the luxury of hacking on matplotlib full time. > (But very briefly, an initial thought: an image is a very special > "thing", and I am reluctant to overload imshow. We may do best to have > separate methods for each distinctly separate case. That can keep both > API and implementation simpler than trying to cram too many variations > into a single method or function.) Seems reasonable. > (Arg! This brings up the *big* question of what should be a class, and > how much functionality, and what kind, should be stuffed into axes > methods.) Ah, yes. That whole "purity" thing. Cheers, Mike > Michael Droettboom wrote: >> John Hunter wrote: >>> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >>> >>>> I've committed my changes on the transforms branch so you can play with >>>> it -- I'm holding off on changing the trunk due to the pending release. >>>> But if everyone agrees on the way to expose this, it would be nice to >>>> merge this over to trunk before the release. >>> >>> Am I right in assuming that the only thing we lose in this approach is >>> faceting (which Eric hates but others may care about)? Since it is >>> orders of magnitudes faster, we could have a pcolor_faceted which >>> pcolor calls the old function if shading='faceted'. Of course the two >>> functions would return different types (image vs patch collection) >>> which is potentially a bit confusing.... We could play with adding >>> faceting to images.... >> >> pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which >> uses pcolor), where the edges of the quadrilaterals are not >> necessarily parallel to the x or y axes. The NonUniformImage stuff >> requires that the quadrilaterals are axis-aligned rectangles. To put >> it another way, the X and Y arrays (that define the mesh) can be >> 2-dimensional for pcolor, but only 1-dimensional for (the new) imshow. >> >> pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, >> but uses optimized quadmesh drawing under the hood, rather than a >> PolyCollection. (Though the comments hint at subtle differences >> related to masking.) >> >> But you are right -- NonUniformImage does not support outlining each >> quadrilateral -- though that may not be hard to add if needed. >> >> The difference in return types is perhaps an argument for >> NonUniformImages going in imshow, not pcolor. (I was thinking only of >> ease of implementation...) >> >> Cheers, >> Mike >> > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
