kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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