matplotlib-devel Mailing List for matplotlib

Would anyone be displeased if I were to reformat all the extension code 
in ansi style? See http://astyle.sourceforge.net/astyle.html. 
Personally, I find the present hodge-podge of styles, and the 
usually-but-not-always 2-space indentation, hard to read and work with; 
I am much more comfortable with the ansi style.
Eric

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

Mike (and others),
The standard rgba format in mpl has been a sequence of 4 doubles, but 
these need to be converted to uint8 before they can be used by Agg, at 
least. Therefore I added the ability for ScalarMappable.to_rgba to 
generate uint8 initially, avoiding the extra translation. (This can 
result in a substantial speedup.) I haven't looked into the other 
backends, but I am wondering whether, at least in the transform branch, 
it might make sense to do this more uniformly--that is, go straight to 
uint8. Or are you already doing this, Mike? Does one ever need more 
than 8-bits per channel of color resolution? Are all the backends in 
fact having to do this conversion from 4 doubles to 4 uint8 anyway?
Eric

All,
Trailing whitespace introduces noise--sometimes a *lot* of noise--into 
svn changesets. I would very much appreciate it if everyone would try 
to eliminate trailing whitespace before committing any changes to svn. 
(And also eliminate hard tabs--I haven't seen many new ones creeping in, 
but continuing vigilence is appreciated.)
Thank you.
Eric