delorie.com/archives/browse.cgi | search |
On 01/28/2016 07:59 AM, Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > The drill-layers are marked as such with a property that is hardwired to > the code that handled connectivity. > > > I would try to keep connectivity and geometry separate if possible. > > Geometry and connectivity needs to be hardwired in the core data > structures. That is the core of what is needed to be efficient while > drawing. > > > Ultimately a layout tool is a connectivity aware drawing package, although some would argue that the connectivity awareness is > optional. You certainly -can- layout a board without net lines, but I think many if not most board designers find them quite useful. The connectivity and geometry are interdependent. If you move a layer up the stack, what is adjacent changes and some of the netlist/ratlines data is now stale. That data can be updated and reconciled by running DRCs usually. Since we almost always use netlist/ratlines data and DRCs, the connectivity doesn't really NEED to be in core data structures -- it can be an attribute associated with a trace or pad's unique ID. One thing needed in core data structures is room for and a mechanism for a unique ID for each atomic board element such as trace, pad, polygon, text... Which brings us to text. Should text be a separate type of atomic board element still? With fonts to swapping out? Could it reduce to a small bitmap and the idea of text and fonts be handled at a higher abstraction level in the code? What about bitmaps? Allow them to be made from square pixels of arbitrary size, or only from other bits of trace atomic board elements?
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |