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.
