The hash table for integer hashes is extremely limited and places most
elements in the same buckets. This leads to a linear search time for
structures built on this.
This blocks hashes, directing the coder to utilize std::set or std::map
structures instead of hash tables for implementing integer-based
lookups.
1) Move a bunch of std::map's to std::unordered_map to get constant-time
look-ups
2) Lengthen progress-reporting intervals to spend more time doing work
and less time talking about it
3) Reverse order of SHAPE_LINE_CHAINs in thermal intersection checks to
make (much) better use of bbox caches
4) Don't re-generate bboxes we already have
5) Fix some autos that weren't by reference (and were therefore copying
large datasets)
6) Rename delta progressDelta so it's easier to search for in future
7) Get rid of a few more autos (because I don't like them)
8) Pass large items to lambdas by reference
Fixes https://gitlab.com/kicad/code/kicad/issues/12130
The change in c9c31fcbc2 missed a number of cases. This reverts back to
the system as it existed before 2be352b9f9
but using the revised method of determining A-B-C distance and avoiding
resizing the arrays
(cherry picked from commit 675a5a6e7b)
Fixes a slowdown caused by erasing elements from the middle of a vector
during a hot loop in SHAPE_LINE_CHAIN::Simplify(). This gets called
quite a bit when loading boards and updating lines, so it needs to be as
fast as possible
Fixes https://gitlab.com/kicad/code/kicad/issues/12115
(cherry picked from commit c9c31fcbc2)
Placing via in walkaround mode and colliding with an arc triggered an
unneeded assertion.
Also fixes the bad assertion format that did not receive strings
(cherry picked from commit df9cf0a0c3)
In addition to showing resolved clearance, we also show the calculated
clearance in the same method as is used for DRC. This will allow users
to better examine their system while working.
Fixes https://gitlab.com/kicad/code/kicad/issues/7934
We now test the midpoint (B) of the 3 consecutive polyline points (A, B, C), since (assuming the angle between AB and BC is > 90 degrees) AC is always longer than
AB or BC. This minimizes the distance computation rounding error (in the previous algorithm, taking the point C for colineraity test) if AB is short and BC is very long, the test would
often fail due to rouding error in projection/line distance computation
We can't know that all holes will be ccw when entering unfracture.
Instead, we set the largest polyline to be the outline and the others to
be the holes.
(cherry picked from commit 1fe956c069)
This also fixes a failure to use the correct effective width for
shapes (which might, for instance, inherit their widths from schematic
defaults, netclasses, etc.).
Fixes https://gitlab.com/kicad/code/kicad/issues/11358
Inflate with linked holes needs to account for fractured polygons,
otherwise inflating with positive value will create rounded divots where
overlapping fracture lines meet and inflating with negative value will
create spaces between fracture lines.
Calling Simplify before Inflate takes an inordinate amount of time as
the Clipper healing routine is rather slow. Our own Unfracture is meant
to heal the results of our Fracture routine and works much more quickly.
After healing, we still call the Simplify routine
(cherry picked from commit 9ca35cbcee)
Clipper can handle complex input polygons but we will sometimes struggle
dealing with outputs from the inflate routine that have degenerate or
overlapping points. Calling Simplify after the inflate keeps our
polygons easier to handle
Fixes https://gitlab.com/kicad/code/kicad/issues/11036
(cherry picked from commit a24cdcb3f0)
Since we use center points to move back and forth for angle and
adjustments, we want to ensure that our center point is stable.
Rounding using integers introduces a 0.5 int uncertainty in each
measurement. These are combined together multiple times to calculate
the center point, which combines the uncertainty. Propagating the
uncertainty to the final calculation allows us to assign a range of true
values and pick the value that is most likely the correct value.
Fixes https://gitlab.com/kicad/code/kicad/issues/10739
1) Generate SHAPE_POLY_SET triangulation by outline so they can be
shared between connectivity system and other clients.
2) Don't add items to connectivity when reading board; we're going
to do a total rebuild anyway.
3) Use multithreading when caching triangulation.
Handles checking output of the arc to ensure we don't end up generating
an invalid arc. Also keeps the limit of the arc angle to be (360,360)
excluding 0.
Fixes https://gitlab.com/kicad/code/kicad/issues/10070
(cherry picked from commit 8fc831cbc2)
Test should not be testing against the polygonization error; if done
correctly that should all be on the correct side of the shape. Use an
epsilon instead (I chose polygonization error / 10, but the value isn't
terribly important).
Fixes https://gitlab.com/kicad/code/kicad/issues/10724
The existing algorithm nicely handled the error being on the inside (where
the segment ends are error-free), but not when it was on the outside (where
the segment midpoints are error-free).
In any case, we want error-free points at each end of the arc so we don't
get ears or divots.
The arc2segment collision should at also include the arc endpoint projections on the segment being tested. Not sure it covers all possible cases, though.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/9023
Clipper might mess up the rotation of the indices such that an arc can be split between
the end point and wrap around to the start point. Detect if this happened and fix it as
required.
Also, handle arcs at the last segment of the chain correctly, meaning we can have arcs
towards the end of the chain that finish at the starting point of the chain.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/9670
Seth Hillbrand
Roberto Fernandez Bautista
Jeff Young
jean-pierre charras
Alex
Tomasz Wlostowski
Mike Williams
Wayne Stambaugh
Marek Roszko
Ola Rinta-Koski
Jon Evans
Johannes Pfister