performance wise i suspect it is polygons that eat computational cycles. I have to wonder also if there could be a way to say that a specific polygon is replicated on several layers.
Igor Izyumin wrote: > On 6/28/07, DJ Delorie <[EMAIL PROTECTED]> wrote: > >> The most likely change I've made is to fiddle with the pin/pad copper >> sizes, or clearances or mask openings. >> > > I suppose this can be a time-saving feature when dealing with small > boards and library footprints, so it should probably be done. I think > it could be implemented just by copying the footprint master with the > modifications. If the user wants to update the footprints, they could > leave the copy alone or replace it with the original. Eventually, > some sort of merge algorithm could try to resolve conflicts. > > >> Also, the location of the >> refdes is part of the element, and we move that around a lot, just as >> we change the refdes text and other texts. >> > > A refdes should not actually be part of the footprint master, it's an > attribute that gets attached to each instance. Right now, it's saved > as simply an XY coordinate offset from the part's centroid. This area > needs improvement, anyway -- for instance, it's impossible to show the > refdes and the value at the same time, since there is only one text > location that gets saved. I would implement it as an attribute that > gets attached to an instance when the instance is created, which can > get rendered into a physical text object if its display is enabled. > A more flexible implementation could allow all sorts of nice features, > like showing part numbers or tolerances or assembly notes imported > from the schematic. > > >> But still, we need to avoid excess computations in the redraw path, >> because redraw is already fairly busy. A cache is fine, or keep an >> "unrotated" element somewhere, or whatnot. >> > > The redraw path should definitely be kept out of this. Having a cache > also helps a lot with online DRC and that kind of thing. > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
