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. (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.) (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.) Eric Michael Droettboom wrote: > John Hunter wrote: >> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> 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 >