Jochen Voss wrote:
I will fix set_linejoin and set_linecap separately at the moment, but
I am also not so happy with the other changes as mentioned above.
OK, I updated to CVS, which fixed the PS problems, many thanks. I then reapplied my patch and fixed it a bit here and there. Here's the new version, against current CVS.
There is no significant win in backends_driver (a couple percent points at best), but no regression either. And in a few places, the code avoids O(N^2) operations, which are the kind of thing that can blow up in your face unexpectedly with a large dataset of the right kind, yet go totally unnoticed in typical usage. I ran the whole backends_driver and looked at the PS, they seem OK to me. Feel free to apply if you are OK with it.
The two routines where there might be really significant gains are
def _draw_lines(self, gc, points):
"""
Draw many lines. 'points' is a list of point coordinates.
"""
# inline this for performance
ps = ["%1.3f %1.3f m" % points[0]]
ps.extend(["%1.3f %1.3f l" % point for point in points[1:] ])
self._draw_ps("\n".join(ps), gc, None)
def draw_lines(self, gc, x, y):
"""
x and y are equal length arrays, draw lines connecting each
point in x, y
"""
if debugPS:
self._pswriter.write("% lines\n")
start = 0
end = 1000
points = zip(x,y)
while 1:
to_draw = points[start:end]
if not to_draw:
break
self._draw_lines(gc,to_draw)
start = end
end += 1000
Currrently, these zip a pair of arrays and then format them into text manually. This means resorting to python loops over lists of tuples, something bound to be terribly inefficient. I can imagine for plots with many thousands of lines, this being quite slow.
However, I'm afraid to rewrite this in a low-level way, because of the numeric/numarray difference. The right approach for this would be to generate a string representation of the array via numeric/numarray, which can do it in C. And then, that can be modified to add the m/l end of line markers on the first/rest lines via a (fast) python string operation.
But since I don't know whether numeric/numarray provide fully consistent array2str functions (I only have numeric to test with), I'm a bit afraid of touching this part. It's also possible that John's backend architectural changes end up modifying this, so perhaps such changes are best thought about after John finishes his reorganization.
But I think the patch is a safe, small cleanup to apply now.
Cheers,
f
backend_ps.diff (7.71 KB)
