|
From: Eric F. <ef...@ha...> - 2012-09-14 23:26:15
|
On 2012/09/14 10:15 AM, Benjamin Root wrote: > > > On Fri, Sep 14, 2012 at 3:50 PM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > On 2012/09/14 9:00 AM, Benjamin Root wrote: > > tricontourf() might be more what you are looking for. Another > > possibility is pcolor() (note that for irregularly spaced grids, > > pcolormesh() would not work). > > Huh? I don't think there is anything pcolor can handle that pcolormesh > can't handle faster. In both cases, the grids must be quadrilateral, > but that's all. > > Eric > > > Clarification: pcolormesh() must have a grid of coordinates (not > necessarially equally spaced). > > As for pcolormesh() being able to handle anything that pcolor() can > handle, I have run into situations where that was not the case. I don't > remember the details, though. I think pcolorfast() operates like that > (falling back to pcolor() as a last resort). No, pcolorfast never falls back to pcolor. In order of fastest to slowest, it tries to use image rendering, then a variant of nonuniform image rendering, and then a quadmesh. It is a bit fussier about inputs than pcolor and pcolormesh, and does not draw lines. pcolor and pcolormesh differ in the mechanism they use (pcolor uses a PolyCollection) and in the way masked data are handled (pcolor draws nothing in masked regions). Eric > > Ben Root > |