This is a little bit like the bounding hull tool, but the
output is "exact" and it only supports the most common
source items.
By 'exact', this means that rounded corners are real arc
segments rather than polygonal approximations. Obviously,
this is rather tricky in the general case, and especially
for any concave shape or anything with a bezier in it.
Envisioned main uses:
* Creating courtyard and silkscreen offsets in footprints
* Making slots around line or arcs.
The one thing that it does not currently do, but which it might
plausibly do without reimplementing Clipper is convex polygons,
which would bring trapezoidal pad outsets for free. But that
is a stretch goal, and bounding hull can be used.
Makes it easier to reason about oval shapes in geometric terms.
For now, this isn't a SHAPE, but it could be (and it's a
fairly common primitive, so it could be useful, though the
obvious use (clearance) is equivalent to a SEG with a clearance,
which is already a function that exists.
This makes it clearer that it is a polyfill-type affair
and make it easier to swap for the std:: one when the
compiler support is guaranteed.
Also avoid double underscores in parameter names,
as well as underscore-capital latter as they are reserved.
In the core geometric types, this can provide some
useful optimisation opportunites.
As most trig functions and std::sqrt aren't constexpr
until C++26, anything that involves a vector length
can't be constexpr yet. But std::clamp and, importantly,
KiROUND are, which does allow quite a bit. And squared
sizes do work, as they are just multiplies, so size
comparisons work too.
The floating point equals-with-epsilon function can't
be directly made constexpr until C++23 (unless std::abs
is replaced with manual code, but that may then forgo
the use of intrinsics at runtime). And they're probably
not important to have at compile-time.
Add a few tests with static_asserts to show/prove that
some non-trivial operations can be done at compile time,
for example BOX2 merging.
This allows better value-semantics and const correctness.
This is a common method, as the Inflate method is
in-place:
BOX2I inflated = other;
// 'Inflated' is not inflated yet
inflated.Inflate( delta );
// Now it is inflated, but it's not const
This is annoying, as the 'inflated' box cannot easily
be made const. Instead:
const BOX2I inflated = other.GetInflated( delta );
If this is just 'int', BOX2D will not Inflate
as you might expect if given an non-integer parameter,
but will instead do a conversion.
Use coord_type, like the two-parameter Inflate method.
Add a test for this.
This is a pretty major rework of the snapping system.
The GRID_HELPERs now have a separate CONSTRUCTION_MANAGER
which handles some of the state involving "construction
geometry".
This is fed with 'extended' geometry (e.g. "infinite" lines from
segments) for use in generating things like intersection points.
It also handles adding this geoemtry to a GAL view item
(CONSTRUCTION_GEOM) for display to the user.
The process is:
* A TOOL creates a GRID_HELPER
* Optionally, it pre-loads a "persistent" batch of construction
geometry (e.g. for an item's original position)
* The grid helper finds useful snap 'anchors' as before, including
those involving the construction items.
* Other items on the board can be 'activated' by snapping to one
of their main points. Then, if it has construction geometry,
it will be added to the display. At most 2 items of this kind of
geometry are shown, plus the original item, to reduce avoid
too much clutter.
The dashed snap lines state machine is also handled in the
CONSTRUCTION_MANAGER and displayed in the CONSTRUCTION_GEOM item.
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.
