Hello, revisions 1.26 and 1.27 introduced some changes
> into the PS backend which I do not quite understand. The
> log messages are "some log optimizations" and "more log
> scaling fixes". What is the problem they try to fix?
> Most of the changes consist in replacements like
> def set_linewidth(self, linewidth): if linewidth !=
> self.linewidth: - self._pswriter.write("%s
> setlinewidth\n"%_num_to_str(linewidth)) +
> self._pswriter.write("%1.3f setlinewidth\n"%linewidth)
> self.linewidth = linewidth
> with the result that a linewidth of 2 is now emitted as
> 2.000 instead of 2. Was this done deliberately? I guess
> that it can result in a significant increase in PostScript
> file size. It also broke set_linejoin and set_linecap,
> which expect integer arguments
I broke this -- thanks for finding it and fixing it -- too much coffee
I guess. Basically, set_linejoin and set_linewidth happen inside a
very nasty inner loop. In lines.py we do (well, "did" -- see next
post)
def _draw_plus(self, renderer, gc, xt, yt):
offset = 0.5*renderer.points_to_pixels(self._markersize)
for (x,y) in zip(xt, yt):
renderer.draw_line(gc, x-offset, y, x+offset, y)
renderer.draw_line(gc, x, y-offset, x, y+offset)
draw_line in backend ps does
def draw_line(self, gc, x0, y0, x1, y1):
"""
Draw a single line from x0,y0 to x1,y1
"""
ps = '%1.3f %1.3f m %1.3f %1.3f l'%(x0, y0, x1, y1)
self._draw_ps(ps, gc, None, "line")
and the _draw_ps behemoth makes 18 million function calls, including
set_linewidth and friends. To help ease the pain a little, I inlined
_num_to_str, and reduced some of the string processing (eg no
stripping of trailing zeros and '.') . I made a number of changes in
ps along these lines, trading a marginally larger file size for fewer
function calls, but screwed up in the process.
Thanks for covering my back!
See followup post for more on this problem.
JDH