On Sun, Apr 02, 2006 at 01:28:06PM -0400, DJ Delorie wrote: > > I tried implementing this once, but it slowed down PCB a lot. In my > case, it was square pads, and I was trying to squeeze another trace > out through the corner. I think I decided to just go with rounded > pads instead. > > Note that this kind of slowdown would be even worse with layouts with > lots of polygons, like yours. > > The problem is that the various output drivers have primitives for > circles and rectangles, but not rounded-corner rectangles. So, we > have to do them ourselves with a collection of circles, arcs, lines, > and/or polygons.
Did you try implementing the rounded corner rectangle as 3 nonoverlapping rectangles plus 4 circles overlapping over that? Or an octagon with 4 overlapping circles? Another possibility would be to have "rendering precision" setting like in some games, which would switch square pin rendering from a rounded corner rectangle to a sharp corner rectangle. But if one needed to route a line around the rectangle he would use the slower and more accurate display. It would be consistent with the already existing concept of thin draw which also doesn't display the board the way it's actually physically looking. Another view mode could be that all primitives would have a thin line around them denoting their clearance which would be useful for checking clearances. The rendering to PostScript and Gerber would be always precise because there, frame rates are not an issue, and doing it imprecisely would result in a damaged board. What about the possibility to add a function for rounded corner rectangle into the call structure for a graphic driver? Gerber and postscript drivers would be given routines that call the rectangle, polygon or circle primitives. Or another possibility is to add a function for rounded corner rectangle into the structure which is allowed to have a NULL value. If the value would be NULL, the caller would assemble the call from polygon and circle calls. CL<
