On 4/10/2012 2:43 AM, jean-pierre charras wrote: > Le 10/04/2012 01:23, Wayne Stambaugh a écrit : >> On 4/9/2012 2:41 PM, jean-pierre charras wrote: >>> Le 09/04/2012 17:37, Wayne Stambaugh a écrit : >>>> On 4/9/2012 9:50 AM, Dick Hollenbeck wrote: >>>>> >>>>> Wayne, regarding: >>>>> >>>>> DRAWSEGMENT::Format(), it concerns me in two minor ways: >>>>> >>>>> case S_SEGMENT: // Line >>>>> aFormatter->Print( 0, "line (pts xy(%s) xy(%s))", >>>>> FormatBIU( m_Start ).c_str(), >>>>> FormatBIU( m_End ).c_str() ); >>>>> >>>>> >>>>> a) I don't think this is s-expression, the xy(...) should be (xy ...) >>>>> >>>>> >>>>> b) It may be worth considering losing one token, namely the "(draw >>>>> line" might be >>>>> "(gr_line". (Really, I am just trying to cover my ass.) I don't >>>>> want to be blamed for >>>>> the slow parsing speed later. :) Any reduction in another token >>>>> that is simple like >>>>> this is worth considering. Each token in the stream is another >>>>> delay, which cumulatively >>>>> may be noticeable. Maybe a common prefix for the graphic primitives >>>>> in this >>>>> DRAWSEGMENT::Format() would allow you to omit one token. >>>>> >>>>> Suggesting "gr_" or something like it prefixed to the primitive, >>>>> instead of a full token >>>>> "draw ". My concern is speed later. However, I'm guessing you are >>>>> reserving the right >>>>> to makes changes later. :) >>>>> >>>>> >>>>> I'm guessing it really gets important on the more common objects like >>>>> tracks and vias, >>>>> *especially tracks*, which end up being about the most common object >>>>> in the file. >>>>> >>>>> >>>>> ALSO: >>>>> ========== >>>>> >>>>> Maybe we can get the (track...) on one line as a default, this will >>>>> help also, since we're using two lines now. >>>>> >>>>> Whitespace in this format is not supposed to matter, but again, I am >>>>> trying to get out of the way regarding parsing speed later. >>>> >>>> As of now, the deepest indentation level is 6 spaces. I know the >>>> indentation is responsible for a lot of the additional file size but >>>> getting rid of it would seriously reduce the readability file. I'm not >>>> sure there is an elegant solution to that problem. >>>> >>>> Wayne >>> >>> Yes, tracks are the most common object in the file. >>> In fact, track is the single object that really needs to be optimized in >>> file. >>> (I have boards with more than 120 000 tracks) >>> In order to reduce the time to read (or write) the brd file, an option >>> could be do not repeat some parameters >>> if they do not change. >>> Mainly track width and track layer values could use the last value read. >>> So consecutive tracks having the same width and layer (very common in >>> Pcbnew) need only 2 parameters (Y and Y coordinates), >>> This trick is often used in many applications. >>> >> >> This could be a nifty optimization. Are the track objects currently >> sorted? This would need to done to maximize this optimization. >> > > Tracks are currently sorted by net and then by proximity. > So net code (and/or net name) should be output only once. > Inside a given net, most of tracks have the same width, > so width parameter should be rarely needed. > > format like: > (tracks > (net 1) > (track(xy 91.6686 85.4837) (xy 91.6686 81.8134) (width 0.6096) (layer 0)) > (track (xy 91.6686 81.8134) (xy 101.6686 85.4837)) > (via (xy 101.6686 85.4837) (size 1.6096) (layerspair back front)) > or: (via thru (at 0.082 0.038) (size 0.08)) > > (track ... ) > ( via (xy 129.6686 95.4837) (size 1.6096) ) > (net 2) > ... > ) > ) > > or something like sounds good for me. > > blind/buried vias need a layerspair definition. > through vias do not need this parameter. > > Note also to minimize time in some search functions, tracks and vias are > "sorted" by proximity > and the track/via order in list should not be modified. > >
I like the grouping by net. This seems more readable to me. Since tracks are already sorted this way, it seems like a natural way to go from the track object to the file output. I may use "layers" instead of "layerspair" and group the tracks by net so it looks something like this: (tracks (net 1 (track (xy 91.6686 85.4837) (xy 91.6686 81.8134) (width 0.6096) (layer front)) (track (xy 91.6686 81.8134) (xy 101.6686 85.4837)) (via (xy 101.6686 85.4837) (size 1.6096) (layers back front)) ) (net 2 ) ) Any one else have any thoughts on this before I make any changes? Wayne _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp