← Back to team overview

kicad-developers team mailing list archive

Re: Removing segment hard-coding

 

Seth,

On 5/16/19 1:29 PM, Seth Hillbrand wrote:
> Am 2019-05-16 08:44, schrieb Seth Hillbrand:
>> Am 2019-05-16 08:31, schrieb Wayne Stambaugh:
>>> Seth,
>>>
>>> I took a look at this and it looks fine to me.  Refresh my memory, is
>>> this change to reduce the number of arc segments to help address the
>>> performance issues on complex boards or is this change for some other
>>> reason?
>>
>> Correct, this reduces the complexity of boards by reducing the number
>> of segments needed to approximate small radius curves.
>>
> 
> 
> Hi All-
> 
> The next step in this is to remove the segment count setting from the
> file format.  I have a baseline patch for this pushed to my segments
> branch at [1].  As this is a file format change, it makes sense to think
> about whether we want to add a an option for the board maximum error at
> the same time.
> 
> Currently, we use 0.005mm as the maximum error for most items.  This
> includes approximating arcs, inflating/deflating for clearances and
> converting items to polygons for plotting.  It may make sense to make
> this value a setting that is stored.  There are a few options I see:
> 
> 1) Put the value in the board file directly.  This might make sense
> because it is used to figure out the copper fills that are stored in the
> file.  But the value itself doesn't directly alter the physical aspect
> of the board.
> 
> 2) Put the value in the board settings.  This would be alongside things
> like layer visibility and plot settings.
> 
> 3) Put the value in the user settings. This would be alongside things
> like anti-alias settings.
> 
> If we go with option (3), we could have a separate value that controls
> the plot output settings stored like (2) so that two users working on
> the same board would get the same output.
> 
> 
> 
> Thoughts?
> -Seth
> 
> [1] https://code.launchpad.net/~sethh/kicad/+git/kicad/+ref/segments

If this setting has any affect on the board output (gerbers) then it
belongs in 1.

Otherwise, I don't have a preference.  You could argue option 2 since
this setting seems like it would be board complexity dependent rather
than application dependent.  I other words, you might want to allow more
error for rendering on a complex board and less error for a simple
board.  You could just as easily argue that it's your system that is
slow and it should be an application setting (3).

Wayne


Follow ups

References