kicad-developers team mailing list archive
Mailing list archive
Re: 6.0 Zone filling differences
Question for you polygon folks:
The old algorithm used to add a lot of pads to a “holes” polygon, then did a Simplify() on it, and then a BooleanSubtract() from the filled area.
The new code does a Simplify() and BooleanSubtract() per pad. Since the holes are all discrete in either case (ie: not overlapping or otherwise interacting with each other), I thought this would have similar performance, and it makes the code easier to understand. But perhaps this is the source of the performance issue?
> On 21 Jun 2019, at 14:16, jp charras <jp.charras@xxxxxxxxxx> wrote:
> Le 21/06/2019 à 14:57, Seth Hillbrand a écrit :
>> Hi Wayne-
>> I don't think that the relief chamfering is controlled by that option.
>> We also don't chamfer the connection on the way into the pad, so I'd
>> tend to agree with Jeff that the extra corner chamfer on only one side
>> of the connection might be unnecessary.
>> It looks like the original knockout code was JP's so I'd be curious to
>> hear why they were originally added.
> The main reason was a problem with the polygon library Kicad was using
> at this time.
> This library frequently created bad polygon shapes due to thermal shapes
> when filling a zone.
> I noticed the bad polygon shapes were much less frequent with the
> chamfered shapes, and when the thermal stubs shape is a X instead of a +
> for round pads.
> Beside, chamfers avoid acute angles in thermal reliefs, especially for
> round (and oval) shapes.
> They are not mandatory, because I am pretty sure most of other ECAD
> tools do not use chamfers, but they create a better shape.
> For me, the main (blocking) issue with the new algo is the calculation time.
> Jean-Pierre CHARRAS
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp