>>>>> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
Eric> Based on a quick look, I think it would be easy to make Eric> LineCollection and PolyCollection accept a numerix array in Eric> place of [(x,y), (x,y), ...] for each line segment or Eric> polygon; specifically, this could replaced by an N x 2 Eric> array, where the first column would be x and the second Eric> would be y. Backwards compatibility could be maintained Eric> easily. This would eliminate quite a bit of useless Eric> conversion back and forth among lists, tuples, and arrays. Eric> As it is, each sequence of sequences is converted to a pair Eric> of arrays in backend_bases, and typically it started out as Eric> either a 2-D numerix array or a pair of 1-D arrays in the Eric> code that is calling the collection constructor. I think this is a useful enhancement. I would think that representing each segment as (x,y) where x and y are 1D arrays, might be slightly more natural than using an Nx2 but others may disagree. How often does it come up that we want a homogeneous line collection, ie a bunch of lines segments with the same properties (color, linewidth...)? The most expensive part of the agg line collection renderer is probably the multiple calls to render_scanlines, which is necessary every time we change the linewidth or color. If all of the lines in a collection shared the same properties, we could draw the entire path with a combination of lineto/moveto, and just stroke and render it once (agg has an upper limit on path length though, since at some point I added the following to draw_lines if ((i%10000)==0) { //draw the path in chunks _render_lines_path(path, gc); path.remove_all(); path.move_to(thisx, thisy); } Ie I render it every 10000 points. Actually, as I type this I realize the case of homogeneous lines (and polys) can be handled by the backend method "draw_path". One possibility is for the LineCollection to detect the homogeneous case len(linewidths)==1 and len(colors)==1 and call out to draw_path instead of draw_line_collection (the same could be done for a regular poly collection). Some extra extension code would probably be necessary to build the path efficiently from numerix arrays, and to handle the "chunking" problem to avoid extra long paths, but for certain special cases (scatters and quiver w/o color mapping) it would probably be a big win. The downside is that not all backend implement draw_paths, but the Collection front-end could detect this and fall back on the old approach if draw_paths is not implemented. JDH _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel