>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> John, I noticed ./examples/dash_control.py -dAgg from the
Steve> latest cvs, is not working..
Steve> I think the problem may be in lines.set_dashes() If I
Steve> change self._dashSeq = seq[1] to self._dashSeq = seq it
Steve> seems to work.
OK, great. Thanks.
Steve> Also, what happened to matplotlib.path - it was being used
Steve> by Cairo for draw_markers()
Hmm. I thought I posted this already. I rewrote the path handling to
use agg paths, which are a more complete implementation (eg supporting
move_rel, line_rel and friends. I found my post as an emacs backup
file, so will just paste it in here -- it provides a code snippent to
convert an agg path to a list path we were using previously.
To: Steve Chaplin <ste...@ya...>
Cc: mat...@li...
Subject: Re: [matplotlib-devel] refactoring the backend drawing methods
From: John Hunter <jdh...@ac...>
Gcc: nnml:outgoing-mail
References: <m3u...@pe...>
<1110376248.3691.24.camel@f1>
X-Draft-From: ("nnml:mail-list.matplotlib-devel" 1256)
--text follows this line--
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> I've implemented draw_markers() for Cairo, and tested it
Steve> using line- styles.py - it seems to be working OK. I did
Steve> find that it caused draw_lines() to stop working and had to
Steve> modify it to get it working again.
Yes, sorry for failing to update you on this.
Steve> I don't think 'fill' and 'fill_rgb' information should be
Steve> encoded into the 'path', and would to prefer to have
Steve> rendering separated into two independent steps: 1) call a
Steve> function to parse 'path' and generate a path - the path is
Steve> a general path (with no fill or colour info) that you can
Steve> later use any way you wish. 2) set colour etc as desired
Steve> and fill/stroke the path.
Steve> The draw_markers() code I've written calls generate_path()
Steve> before drawing each marker and it reads the fill value and
Steve> the fill_rgb each time which it unnecessary since the
Steve> values are the same for all the markers. Passing the
Steve> fill_rgb as an extra argument to draw_markers() would be
Steve> one way to 'fix' this.
Done. I also wrapped agg's path storage and am using this rather than
the list storage. You can get the old representation from the new
rather easily, as illustrated here
import matplotlib.agg as agg
path = agg.path_storage()
path.move_to(10,10)
path.line_to(20,30)
path.curve3_rel(100,200)
path.end_poly()
print [ path.vertex() for i in range(path.total_vertices())]
Steve> Cairo (and probably Agg, PS, SVG) supports rel_move_to()
Steve> and rel_line_to () - so you can define a path using
Steve> relative rather than absolute coords, which can sometimes
Steve> be useful. For example, instead of translate(x,y)
Steve> generate_absolute_path(path) stroke() you can use
Steve> move_to(x,y) generate_relative_path(path) stroke() and the
Steve> path is stroked relative to x,y with no need to translate
Steve> the coordinates.
agg has move_rel and line_rel, etc, but I don't think it works the
same way, because it computes the actual move_to, line_to, etc under
the hood and stores these values, so I'm not sure it's possible to
actually store a relative moveto in agg. Could be missing something,
though. As far as I can see, everything gtes converted to one of the
6 primitive commands (STOP, MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY)
under the hood.
JDH
|
