kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 6/5/19 11:55 AM, Seth Hillbrand wrote:
> On 2019-06-05 10:09, jp charras wrote:
>> Le 05/06/2019 à 15:40, Wayne Stambaugh a écrit :
>>> On 6/5/19 7:20 AM, jp charras wrote:
>>>> Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit :
>>>>> On 6/4/19 4:25 PM, Seth Hillbrand wrote:
>>>>>> On 2019-05-31 07:25, Wayne Stambaugh wrote:
>>>>>>> On 5/30/19 4:53 PM, Seth Hillbrand wrote:
>>>>>>>> On 2019-05-30 15:00, jp charras wrote:
>>>>>>>>> Le 29/05/2019 à 21:31, Seth Hillbrand a écrit :
>>>>>>>>>> On 2019-05-29 10:33, jp charras wrote:
>>>>>>>>>>> Attached a patch that modify the way filled areas (solid
>>>>>>>>>>> polygons)
>>>>>>>>>>> are
>>>>>>>>>>> built in copper areas.
>>>>>>>>>>>
>>>>>>>>>>> Currently, solid polygons are slightly smaller than the exact
>>>>>>>>>>> area, and
>>>>>>>>>>> the polygon outlines have a thickness to fill the exact area.
>>>>>>>>>>> With this patch, polygon outlines have no thickness and the
>>>>>>>>>>> polygons
>>>>>>>>>>> have the exact area.
>>>>>>>>>>>
>>>>>>>>>>> To test it on a given zone, the zone setting must be edited
>>>>>>>>>>> with the
>>>>>>>>>>> "Fill polys without thick outline" checked.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi JP-
>>>>>>>>>>
>>>>>>>>>> Why did you decide to make this a user option?  Is there some
>>>>>>>>>> feature
>>>>>>>>>> that it prevents that a user would want for some areas but not
>>>>>>>>>> for
>>>>>>>>>> others?
>>>>>>>>>>
>>>>>>>>>> I tested it with a large board and it reduces the polygon point
>>>>>>>>>> count by
>>>>>>>>>> almost 50% (!) for complex fills.  If I zoom in on an edge, it
>>>>>>>>>> appears
>>>>>>>>>> that the approximation count is substantially coarsened by the
>>>>>>>>>> patch. 
>>>>>>>>>> See attached image.  The edge on the right is with the new option
>>>>>>>>>> enabled.  The edge of the left is without the new option.
>>>>>>>>>>
>>>>>>>>>> I didn't find any other issues.  Large boards were much faster
>>>>>>>>>> and
>>>>>>>>>> DRC /
>>>>>>>>>> plotting appear consistent between options (with the exception
>>>>>>>>>> noted
>>>>>>>>>> above)
>>>>>>>>>>
>>>>>>>>>> -Seth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks Seth for your test.
>>>>>>>>>
>>>>>>>>> Currently, having a user option is useful to test and compare
>>>>>>>>> the 2
>>>>>>>>> options (the current way, and the new way).
>>>>>>>>
>>>>>>>> OK.  Makes sense.  Instead of changing the board file, can we
>>>>>>>> put the
>>>>>>>> option in the advanced config file to enable our testing?  It
>>>>>>>> would be
>>>>>>>> nice to avoid changing the file format here.
>>>>>>>
>>>>>>> I agree that the board file format should not change for rendering
>>>>>>> configuration.  Please make this a user option.
>>>>>>
>>>>>>
>>>>>> Hi JP-
>>>>>>
>>>>>> Did you mean to push eb1faebf1?
>>>>>>
>>>>>> -Seth
>>>>>
>>>>> I thought this was not going to require any board file version
>>>>> changes.
>>>>>  Did I miss something here?
>>>>>
>>>>> Wayne
>>>>>
>>>>
>>>> Some clarification:
>>>>
>>>> I pushed some changes because maintaining my local branch against all
>>>> changes in master branch was not always easy.
>>>
>>> I know keeping things rebased given the current development churn but
>>> you should have held off committing the file format change before
>>> committing the rest of the code that actually does anything with the
>>> file format changes.  How much longer before you merge the rest of the
>>> changes?  If it's going to be too long, we should probably revert your
>>> initial commit.
>>
>> I'll commit the last change (in zone_filler) very soon.
>> It is finalized on my computer and looks good.
>> I just want to make more tests.
>>
>> Currently, the file format is not modified.
>> ( changes are not yet enabled, because variables inside the code are
>> fixed to a default value to use the current zone filled polygon way).
>>
>> When finalized, the new zone filling will be used only if the user
>> activate it (until it become the default, after many tests)
>> When not activated, the file format has no change.
>>
>> Commit eb1faebf1 prepares the change, but does not activate it.
> 
> 
> Could we see and test what the changes are before they are committed? 
> I'm happy to use your launchpad branch if you could push it there.  If
> we are not making this a simple advanced config option, it would be
> helpful to go over the details.
> 
> 
> Best-
> Seth
> 

I wouldn't mind doing some more testing as well given the complexity and
potential issues with this change.  Having a public repo to clone from
would make life easier than patch sets given the amount of code changes.

Wayne