Re: gEDA-user: gschem with b-spline paths and filled sections

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sun, 2008-05-04 at 09:29 -0400, Ales Hvezda wrote:
> [snip]
> >	Questions, why didn't you use gdk's simple polygon API for this?
> >

Mainly because I was working off the top of my cairo_experiment branch,
and that the polygon API doesn't allow curved path segments. The
internal representation is (similar to rsvg), a node list with 3 sets of
(x,y) control points, and an operation type. (lineto, moveto,
moveto_closed, curveto, endpath).

I'm not 100% certain how useful curved path sections are, so if its too
dumb - and people don't want it, we could just choose to support the
non-curved path elements. (Least common denominator too).

> 	And before this line of questioning is questioned..., I'm not
> opposed to using cairo as a rendering mechanism, just as long as it is
> completely optional (for a while, just like gtk v1 vs gtk2) and that
> there is some level of feature parity between the cairo and non-cairo
> rendering
> (e.g. it would be unfortunate if polygons were a cairo only feature).

No reason we couldn't slot in a GDK based drawing function too, although
we'd either have use Bezier subdivision to approximate the curved paths,
or choose to disallow those paths.

I don't think any of us want to turn gschem into a fully featured vector
graphics / CAD package (in the non electrical sense of the word) - there
is no use-case for it, so there comes a point where we simply don't
bother striving for these features.

Since cairo handed me Bezier curves on a plate, and the code for
rendering SVG path strings was re-used with only minor alterations. (SDB
will be pleased to note that is copy-paste, not an external library.)

Sometimes I get tired of coding to the least common denominator, but
mostly the fact that these operations _are_ slow is more frustrating.
Surely drawing a few curves on screen should be lightning fast nowadays!
The 3D CAD package I use certainly manages some pretty complex geometry
at decent frame-rates thanks to OpenGL and my video chip's modest
abilities there.

> 								-Ales
> 
> PS. The arbitrary paths as well as the anti-aliasing are quite nifty,
> but these capabilities come with a performance penalty unfortunately.  :-(
> Like for instance the high quality rendering mode in gerbv, very very nice
> looking, but I wouldn't want to be forced to use that mode all the time.


Hopefully cairo's performance will continue to improve. I've seen sse2
fast-paths being added to pixman recently, and think there is a gSoC
project to implement a different (faster) rasteriser. Unfortunately,
sse2 doesn't help those with old computers :(.

The cairo code will co-operate with GDK drawing. Use either / or. The
thing you can't do with cairo is XOR - so I left the old GDK code for
rubberbanding. Similarly, erasing objects by drawing over them with the
background colour leaves anti-aliasing artifacts unless you bloat the
object.

Since in general, just painting background colour doesn't give us a
clean erase, the cairo_experiment branch switches the drawing model
(again), to do all painting from the expose handler. To erase, we just
make an invalidate call on that portion of the screen.

I may experiment with re-adding a persistent backing-store again, with
an invalidate region model used internally to keep that pristine.
> 

-- 
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-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user