>>>>> "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

Reply via email to