On Thu, 2008-10-09 at 06:43 -0700, [EMAIL PROTECTED] wrote: > On Oct 9, 2008, at 2:55 AM, Peter Clifton wrote:
> Yes. Each (leading) vertex represents an event. All the > intersections represent the sweep status. The algorithm can move > multiple events to the status list. > > The polygon is rotated so the sweep line runs parallel to the hatch > lines. Resulting hatch line segments are rotated back to the original > space. So the sweep line runs at an angle through the shape to be > filled. Thanks for the explanation. I'm not an "algorithms" guy normally, so that helped. Sounds similar to some polygon rasterisation algorithms. IIRC, cairo was looking at scan line based things, but at the moment they tessellate the polygons first. > >> For the public interface, I'm suspecting wrapper functions in files > >> like s_box*, s_circle*, o_box*, or o_circle*. I'm open for ideas on > >> the function signatures. > > > > Or we could expose the m_hash_... functions. > > I'd rather abstract the functions a bit more. It leaves the > opportunity for algorithm changes, such as lazy evaluation, as you > suggest below. These functions don't lend themselves to lazy > evaluation. However, if the OBJECT was passed in, that would work > quite nicely. Also, if the pitch gets small enough, the program > should probably just use a solid fill. Actually, (typically), I hadn't thought about lazy evaluation, but that could be provided with a o_..._get_prim_objs() function which would trigger their calculation if they aren't up-to-date. I was thinking about keeping them generated and valid all the time, but that probably isn't necessary. (Just like bounds - Peter B is looking to add lazy evaluation as an extension to bounds caching. This is since if we use pango, the real bounds of text depends on the renderer. The idea was to ask gschem for the bounds on a lazy basis.) > Probably a good idea. Subdivided paths could also be cached, but I > believe there is a Bezier subdivision algorithm fast enough not to > worry. I hope so. I'd really like to keep the objects cached within libgeda scale independent. Since you'd tend to cut off subdivision once a certain precision is reached, it is probably best this stays in the GUI. (Also, Cairo / Postscript output does not need subdivision). > > The only thing which niggles at the back of my mind, is that I just > > almost killed prim_objs for text, as rendering lots of little lines > > (cairo especially) turned out to be slow compared to using pango. > > Hashing using cairo patterns is a possibility, even if it doesn't help > > our postscript output. > > Didn't try the algorithm with Cairo. However, I'd prefer the same > algorithm for both display and print to preserve the WYSIWYG. That is fair enough. The only thing which isn't the same at the moment, is fonts. Printing goes through our hand-crafted postscript output, and on-screen goes via generated prim_obj, or cairo functions. Postscript output is prim_obj based, or using some named postscript font. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
