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.
No, now is a good time. Right now I'm proposing the *addition* of a
new method to the backend, with the *eventual* deletion of redundant
methods. draw_lines is one of those core methods that I think
deserves to remain and be highly optimized.
> 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.
Actually, I think the right way to do it me to save the x and y arrays
as postscript arrays, and then generate the postscript for loop to
iterate over the arrays at postscript render time. Then we have
no loop in python and smaller file sizes. I think this approach in
general could be a big win in PS both in terms of file size and file
creation times. The major feature of postscript that the mpl backend
currently underutilizes, dare I say almost ignores, is that postscript
is a programming language.
I'll leave it to Jochen to decide on the patch and/or apply it -- on
my quick read the changes look sensible, and since it passes
backend_driver, it must be good!