On Wed, 2008-10-08 at 20:49 -0700, [EMAIL PROTECTED] wrote:
> This patch includes support functions for hatching arbitrary  
> polygons.  Currently only private functions within libgeda have been  
> created.  The public interface for this functionality has not been  
> designed.    However, these functions have been tested using a kludge  
> by calling them directly from gschem.
> 
>  From my initial design, the file m_geometry.c was getting a bit  
> "heavy," and needed to be split up.  So, this patch contains an  
> m_transform.c and an m_hatch.c.

Very cool. What algorithm does this use?

Looking at the line output code, it appears that it iterates over a
starting y coordinate for begining a sweep. Does that necessarily work
for non-convex polygons, where we might have two hashings starting at
the same Y coordinate?

e.g.:
 ___________
|///////////|
|///////////|
 \/////\////|
  \///  \///
   \/    \/

> 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 wonder though, we could actually calculate these lines as "prim_objs"
of the element being hashed, e.g. cache the geometry in libgeda, then
stuff them through the normal drawing routines. Libgeda would regenerate
the prim_objs just like regenerating text, when any hashed fill is
selected, and the object is changed in any way. (I'm presuming no
hashing during rubberbanding).

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.

Anyway.. I guess drawing lines is the way we do it now, and its not too
slow. I really like the prospect that your code will simplify the
drawing routines in gschem.

When I get a chance I'll see if I can knock up a test branch (perhaps on
top of the cairo code) where we can exercise these functions for real
drawing.

Keep up the good work!


Best wishes,

-- 
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

Reply via email to