Re: gEDA-dev: Thoughts about the PCB database model

[Steve Meier <smeier-at-NOSPAMalchemyresearch_dot_com>]

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



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev