collection efficiency improvement

Based on a quick look, I think it would be easy to make LineCollection and PolyCollection accept a numerix array in place of [(x,y), (x,y), ...] for each line segment or polygon; specifically, this could replaced by an N x 2 array, where the first column would be x and the second would be y. Backwards compatibility could be maintained easily. This would eliminate quite a bit of useless conversion back and forth among lists, tuples, and arrays. As it is, each sequence of sequences is converted to a pair of arrays in backend_bases, and typically it started out as either a 2-D numerix array or a pair of 1-D arrays in the code that is calling the collection constructor.

Using a single 2-D array makes it easier to determine whether one is dealing with 'old-style' inputs or 'new-style' inputs, but it might still be reasonable to allow [X, Y] instead or in addition, where X and Y are 1-D numerix arrays.

Any objections or alternative suggestions?

Eric

I have one suggestion, slightly off-topic, and I'm not sure how useful it would be: you might think about making LineCollection accept a 3-D numerix array. This came up for me while I was looking at turning the quiver arrows into line segments. As I understand it (and as the documentation says) LineCollection takes a set of a lines which are composed of continuous line segments, like:

segments = ( line0, line1, line2 )
linen = ( (x0,y0), (x1,y1), (x2, y2) )

I'd like an extra level of organization, like so:

linegroups = ( group0, group1, group2)
groupi = ( line0, line1, line2 )
linen = ( (x0,y0), (x1,y1), (x2, y2) )

Where "linegroups" would be the input to LineCollection. I assume it's fairly obvious how this turns into a rank 3 array.

The reason for this is that it allows for the drawing of non-continuous lines. This came up with the quiver arrow stuff because, as it stands, drawing a line-based arrow requires you to back-track over a previous line at least once. This created some rendering problems, where the back-tracked line was darker than the others, at least on the agg backend. This can be fixed by backtracking along every line in the arrow, so you are essentially drawing the arrow twice, but that seems inefficient. It is possible to draw 3 seperate line segments for each arrow, but then the colormapping no longer works; each line segment gets a different color, and the arrows look like a mess.

As I said, I don't know how useful this would be; it only comes up when drawing non-closed line segments that need to be addressed as a single object. Does what I wrote make sense?

Jordan

Eric Firing wrote:

ยทยทยท

Based on a quick look, I think it would be easy to make LineCollection and PolyCollection accept a numerix array in place of [(x,y), (x,y), ...] for each line segment or polygon; specifically, this could replaced by an N x 2 array, where the first column would be x and the second would be y. Backwards compatibility could be maintained easily. This would eliminate quite a bit of useless conversion back and forth among lists, tuples, and arrays. As it is, each sequence of sequences is converted to a pair of arrays in backend_bases, and typically it started out as either a 2-D numerix array or a pair of 1-D arrays in the code that is calling the collection constructor.

Using a single 2-D array makes it easier to determine whether one is dealing with 'old-style' inputs or 'new-style' inputs, but it might still be reasonable to allow [X, Y] instead or in addition, where X and Y are 1-D numerix arrays.

Any objections or alternative suggestions?

Eric

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel