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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA