Removing existing fills will prevent re-drawing invalid polygons before
they are ready. This seems to happen on Macs more easily due to redraw
timing.
Fixes: lp:1819553
* https://bugs.launchpad.net/kicad/+bug/1819553
This was due to the stub removal tests if a stub end is outside a solid area to remove it.
There is a corner case: is the stub end is exactly on a solid area outline extra segment
created by Fracture() used in calculations.
The stub removal tests are now made before fracturing.
Fixes: lp:1819317
https://bugs.launchpad.net/kicad/+bug/1819317
No net zones, by definition, do not connect to any other element.
Therefore, the entire net is an island and should not be removed by the
knockout section
Fixes: lp:1811239
* https://bugs.launchpad.net/kicad/+bug/1811239
Non-connected zones are, by definition, not connected, therefore, we
should not knock out thermal reliefs under any case
Fixes: lp:1810989
* https://bugs.launchpad.net/kicad/+bug/1810989
Where we can get away with lower segment counts (localizing an anchor),
we keep the low-def 16 segment count. Intermediate values and values
that are visible to the user are set to high definition. Most are
simply hints to the inflation correction but where they show, the user
show see smooth lines.
Most rounding operations have been shifted to an absolute error
calculation and the ability to adjust zone segment counts has been
removed in 5.1. The remaining elements that use fixed segment counts
are either 18 (DRC) or 32 (plotting). This aligns the punchout segment
count with the higher (32) definition value
Rather than depend on proper unlocking for each exit, we move the
connectivity lock mutex into an RAII-type configuration that
automatically unlocks on exit.
This allows people to continue to use the edge-width as a proxy
for board edge clearance until we implement board edge clearance
as a real feature.
Fixes: lp:1797787
* https://bugs.launchpad.net/kicad/+bug/1797787
The evaluation of count_if resulted in a 0 or 1, leading to segment zone
fills always running on single processor and the progress bar showing
incorrect status. Likely infrequently hit as only affected segment
fills.
This is a boyscouting commit to standardize the threading of zone fills.
We do not need to join threads after their completion, instead we simply
allow them to clean up their memory without blocking the user. This
also sets the maximum number of threads that may be created to the
number of zones being filled. More than this will only leave un-used
threads being created and immediately killed.
We also include the connectivity search as a phase in the fill progress
reporter. This was the case before but did not utilize the correct
maxsize, leading to stalled progress bar.
Using Title + Message wasn't working for all the dialogs which
did substitutions in the message (which was a lot of them).
Fixes: lp:1789348
* https://bugs.launchpad.net/kicad/+bug/1789348
There are three related changes here to harden our handling of threads
in the footprint async loader.
1) Footprint async loader explicitly aborts any remaining loader threads
on exit.
2) We protect the thread join by a mutex
3) We do not pause during no-wait routines
m_Zone is a fully deprecated list of SEG_ZONE items (similar to TRACK), used to fill copper zones in *very old* boards.
it is even unlikely there are still boards that use them.
So it should be removed one day.
On OpenMP single core systems only the first thread launched. It means
that only the UI updating thread was running, without the one
responsible for actual computation. It is fixed by enforcing at least
two threads.
The calculation was made too early, before removing insulated islands.
Note: filling zones with segments is an old option, not very useful:
using only polygons has never created issues in gerber files.
Seth Hillbrand
jean-pierre charras
Jeff Young
Maciej Suminski
Jon Evans
Tomasz Włostowski