Put these in a separate header - they don't need to be available
whenever VECTOR2 is, but they are generic, reusable functions that
can have the corner cases defined and tested.
Probably doesn't add much directly, but it documents and
enforces the implied contract that the hash is fixed,
and could be used for, say, compile time hash tables.
SHA256 is fine for one-offs but for large libraries where we might be
running the hash on hundreds of files, the speed difference is
appreciable. We don't require crytographic hashing, just a check that
the original file hasn't been corrupted so Murmur3 satisfies our basic
requirement.
Issue raised by TomW, points included in new QA test where Simplify was
not properly removing colinear points.
Also removed TestSegmentHitFast() as the speed gains were minimal when
testing against the revised SEG::SquaredDistance routine in
TestSegmentHit()
This allows to see what the current snap point is, which is useful when
zoomed in, or the point is like the corner of a rounded pad where it's
"in free space" and might not be immediately obvious.
We are calculating the same value in two different ways. If there is an
off-by-one issue in our calculation along axis, this still means that it
was a direct hit on the line as seen in the unit test cases
This means that it doesn't start consuming hotkeys for
IME composition in the main canvas on Linux.
Text boxes in dialogs and the property manager, for example,
still receive IME composition.
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/9882
Previous function would drop some KiROUND calls due to inability to
parse the () operator. Using the _v template gets the constexpr check,
allowing us to avoid the conditional while running
We don't actually need the closest point to figure out the distance.
Since this calculation is used everywhere, we see some non-negligible
gains by picking the length along the projection
line chains that are not closed should avoid simplifying between
beginning and end points. Make sure that we keep the finishing point
for these chains
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18409
(cherry picked from commit b71eb1186f)
When calculating a part of the polygon area and thus ending the polygon
at the specified vertex aEnd we need to calculate and add the area below
the needed additional line from "aEnd" to "this" to close the resulting
partial polygon. As in this case VERTEX* p references "aEnd" after exiting
the do-while loop the correction term in the if-statement was always
evaluated to zero. Change "aEnd" to "this" in the correction term.
Previously, fills could end up just barely touching, leading to DRC
errors even if there was enough room to fill the remaining space. This
was due to how we shrink/expand the zones to remove small features. By
adding a zero-width line between points that should be connected, we
expand back to the correct width.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14130
Only do tests between 3 polygon pairs with closest bbox centers.
Only do tests between 5 parts of line chain pairs with closest bbox centers.
Gets OptimizeRNEdges down to 350 ms
See https://gitlab.com/kicad/code/kicad/-/issues/18148
The VERTEX_SET is useful when we need to quickly find elements that are
close to each other. Extracting to a mixin keeps the code from
diverging between implementations and simplifies that maintenance.
Add direct handling of quadratic beziers to save compute time and number
of points. Update cubic interpolation to reduce number of points
generated for a given smoothness
Cache data on open and used cached data to avoid multiple re-calcs
Remove minimum line length and number of segments and replace with
standard max error level. Allows us to specify the tolerance of bezier
interpolation
VECTOR + scalar = vector type (KiROUND when VECTOR is integral and
scalar is float)
VECTOR + VECTOR = common type vector
Implemented with concepts in template rules - SWIG compatible
The previous overflow handling code casted the int_min value into an
unsigned, meaning that the min value and max value were almost the same,
clamping the output to unreasonable values.
Updated code handles floating points first, then does integer casting
through int64_t
This forces the operators -, +, * to use standard promotion rules when
operating on vectors of two different types. Previously, this depended
on the order in which the operator was called, so subtracting a VECTOR2D
from a VECTOR2I could have a different result than negating the result
of subtracting the same vectors in the opposite order
Since the addition of all nets to the net navigator, performance on very
complex designs is unacceptable. Not updating the net navigator is a
cheap and dirty short term fix. Users with complex designs will not be
able to use the net navigator. A better fix to resolve the performance
issues needs to be implemented.
