John, I noticed ./examples/dash_control.py -dAgg from the
> latest cvs, is not working..
> I think the problem may be in lines.set_dashes() If I
> change self._dashSeq = seq[1] to self._dashSeq = seq it
> seems to work.
OK, great. Thanks.
> Also, what happened to matplotlib.path - it was being used
> 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 <stevech1097@...49...>
Cc: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] refactoring the backend drawing methods
From: John Hunter <jdhunter@...5...>
Gcc: nnml:outgoing-mail
References: <m3u0on14wc.fsf@...165...>
<1110376248.3691.24.camel@...51...>
X-Draft-From: ("nnml:mail-list.matplotlib-devel" 1256)
--text follows this line--
> I've implemented draw_markers() for Cairo, and tested it
> using line- styles.py - it seems to be working OK. I did
> find that it caused draw_lines() to stop working and had to
> modify it to get it working again.
Yes, sorry for failing to update you on this.
> I don't think 'fill' and 'fill_rgb' information should be
> encoded into the 'path', and would to prefer to have
> rendering separated into two independent steps: 1) call a
> function to parse 'path' and generate a path - the path is
> a general path (with no fill or colour info) that you can
> later use any way you wish. 2) set colour etc as desired
> and fill/stroke the path.
> The draw_markers() code I've written calls generate_path()
> before drawing each marker and it reads the fill value and
> the fill_rgb each time which it unnecessary since the
> values are the same for all the markers. Passing the
> fill_rgb as an extra argument to draw_markers() would be
> 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())]
> Cairo (and probably Agg, PS, SVG) supports rel_move_to()
> and rel_line_to () - so you can define a path using
> relative rather than absolute coords, which can sometimes
> be useful. For example, instead of translate(x,y)
> generate_absolute_path(path) stroke() you can use
> move_to(x,y) generate_relative_path(path) stroke() and the
> path is stroked relative to x,y with no need to translate
> 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