Mike (and others interested in speed),
I have committed an experimental Axes method temporarily called "pcolorfast" that uses one of three methods for rendering a pcolor-type plot: an image, a nonuniform image (new implementation in _backend_agg.cpp), and a quadmesh. Based on the calling signature and the characteristics of the input grid it selects the fastest method. The image and nonuniform image are very fast; quadmesh, which is used only if the grid is not obviously rectilinear, is much slower, but still enormously faster that plain pcolor if the grid is large.
A peculiarity of the method is that what it returns depends on which method it picks. It always returns a ScalarMappable, though, so I think the other differences are acceptable.
Another peculiarity is that when image-type rendering is used, writing a ps file is still fast and efficient, and the file has a reasonable size; with quadmesh rendering, a ps file is written based on a polygon collection, so it can easily become huge and horribly slow to write. It would be better if we could change the default file writing to use an image method; then all three methods would perform more similarly on all backends. This could involve moving quadmesh from collections to image, and changing quadmesh so that it actually returns an image-like entity. This is probably getting beyond my abilities, though.
Long-term, I suspect we will want to keep two pcolor-like methods: the original, which does everything with a patch collection, and can draw edges; and a modification of pcolorfast (maybe renamed pcolorimage) that does everything in an image-oriented mode, and does not draw lines. Pcolorfast is for dense grids, and lines simply are not useful with dense grids. (Yes, if there are strong requests from users the line-drawing could be added back to pcolorfast.)
Eric
pcnon2.py (943 Bytes)