There were two problems in the triangulation caching
of SHAPE_POLY_SET:
First there was a double free:
While SHAPE_POLY_SET implements the copy constructor,
it did not implement the operator=, which resulted
in the default operator= being generated by the
compiler. The default operator= copied the member
m_triangulatedPolys, which is a std::vector of pointers.
So after operator= execution, there are two SHAPE_POLY_SET
having pointers to the same TRIANGULATED_POLYGONs, each
of them deleting them in their destructors. This led
to segfaults, because calling
TransformShapeWithClearanceToPolygon on a Zone
uses operator= to copy the contained SHAPE_POLY_SET.
The new SHAPE_POLY_SET then went out of scope and
deleted the cached triangulation within the Zone.
This first problem is fixed by implementing operator=
for SHAPE_POLY_SET.
Second, there was a memory leak: Calling
"CacheTriangulation" on a SHAPE_POLY_SET,
then changing the polygon and then calling
"CacheTriangulation" again led to
leaking the
triangulations generated in the first call.
This second problem is fixed by holding
the cached triangulations in a unique_ptr.
SHAPE_POLY_SET: fix crash in VertexCount when it is a empty poly set, or when params are incorrect.
minor other fixes:
warning in degug mode in dialog_dxf_import_base.cpp
pcb_painter.cpp: remove a useless debug line.
The recent refactoring work to move zones from CPolyLine to
SHAPE_POLY_SET resulted in a reduction in pcbnew's python
capabilities. This change exposed SHAPE_POLY_SET to restore
that functionality (albeit with slightly different method names)
Removes the need of using the legacy code in polygon/PolyLine.{h,cpp},
refactoring all CPolyLine instances with SHAPE_POLY_SET instances.
The remaining legacy methods have been ported to SHAPE_POLY_SET;
mainly: Chamfer, Fillet, {,Un}Hatch.
The iteration over the polygon vertices have been simplified using the
family of ITERATOR classes.
In polygon calculations (combining polygons, fracture) the mode of calculation (fast or strictly simple polygon option) as no more a default value, because choosing the best mode is better to optimize the calculation time.
In 3D viewer, this option can take a *very long* calculation time (minutes instead of seconds, or hangs) and they are now using aFastMode = true to do polygon calculations, especially for zones inside zones belong to the same net but having different priority (which creates weak polygons).
aFastMode = false is the default for other calculations (zone filling) as before.
Jon Evans
jean-pierre charras
Tomasz Włostowski
Camille
Andreas Buhr
Miles McCoo
Alejandro García Montoro
Simon Richter
Mario Luzeiro
Maciej Suminski