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