Ryan, The pcolor implementation is fundamentally unsuited to large arrays. Therefore I made the pcolorfast axes method, which tries to use the fastest available Agg extension code, depending on the characteristics of the spatial grid. If the grid is rectangular and regular in both directions it uses a slight modification of the image code; if it is rectangular but with irregular spacing, it uses the nonuniform image code; and if it is not rectangular it uses the quadmesh code. It sounds like what you need is the quadmesh version, which you can access either via pcolormesh or pcolorfast. Neither is exposed via the pylab or pyplot API at present; both are axes methods. The pcolorfast API also may change slightly in the future; it probably needs a little more work.
The quadmesh code has problems with masked arrays in the released version of mpl, but not in the svn version. It is *much* faster than pcolor, but may not be fast enough for your needs. If you are looking into what sounds like an OpenGL backend, or component to a backend, then the place to start is still probably pcolormesh or pcolorfast, not pcolor. Eric Ryan May wrote: > Hi, > > I've been poking around with pcolor, trying to see what makes it tick, > since its performance is biggest thing that drives me nuts about > matplotlib. I do pcolor plots of weather radar data with ~100000 > polygons in them. Unfortunately, these polygons are at best trapezoids, > so I can't treat it as image data. With this data, pcolor takes ages to > zoom and pan, even on my new workstaion. My end goal is to be able to > use OpenGL to do some 2D rendering, since in my experience, this simply > flies at rendering such data for interactive analysis. > > I noticed that when I run the pcolor_demo.py (using current SVN trunk), > 29396 separate calls are registered to RendererGDK->draw_path to simply > draw the image the first time. Is there any reason why these can't be > batched up and passed in one block to the renderer? This would make > life easier in setting up OpenGL to render in one pass. > > Thanks > > Ryan > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
