kicad-developers team mailing list archive
Mailing list archive
Re: [RFC] Test for Copper zones using solid polygons without outline thickness.
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
built in copper areas.
Currently, solid polygons are slightly smaller than the exact
the polygon outlines have a thickness to fill the exact area.
With this patch, polygon outlines have no thickness and the
have the exact area.
To test it on a given zone, the zone setting must be edited
"Fill polys without thick outline" checked.
Why did you decide to make this a user option? Is there some
that it prevents that a user would want for some areas but not
I tested it with a large board and it reduces the polygon point
almost 50% (!) for complex fills. If I zoom in on an edge, it
that the approximation count is substantially coarsened by the
See attached image. The edge on the right is with the new
enabled. The edge of the left is without the new option.
I didn't find any other issues. Large boards were much faster
plotting appear consistent between options (with the exception
Thanks Seth for your test.
Currently, having a user option is useful to test and compare
options (the current way, and the new way).
OK. Makes sense. Instead of changing the board file, can we put
option in the advanced config file to enable our testing? It
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.
Did you mean to push eb1faebf1?
I thought this was not going to require any board file version
Did I miss something here?
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
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.