* [CAM] fix biggest performance problems in ramp dressup
key items:
- finding the index of the current edge with edeges.index(edge) was very
expensive; fixed by tracking the index while looping
- checking which edges were rapids with edge equality was also
expensive; fixed by keeping a list of indexes of rapid input edges,
and tagging output edges with whether or not they are rapids
* [CAM] comment out Path.Log.debug in hot segments of ramping code
Even when low level logs are supposed to be suppressed, Path.Log.debug
takes take invoking traceback.extract_stack. This time adds up if logs
are invoked in frequently run loops.
* Fix CAM test
* [CAM] reimplment ramp method 1 with faster code
* [CAM] reimplement ramp methods 2, 3, and helix
* [CAM] patch to make output match original
* [CAM] ramping full performance + functionality fix
This reverts commit 7e62d07538 and adapts
to the in between commits where necessary.
- CAM: apply precommit 7274dac185
- CAM: rename "Tests" to "CAMTests" 2ff4914fd8
Motivations for the revert:
- Instead of actually implementing #14364 only a search and replace in
the enums values has been performed. But this does not mean the
feature is there, becasue "climb"/"conventional" milling depends not
only on the path's direction, but also on the spindle direction and
whether the milled feature is "inside" or "outside".
- In half of the cases of every changed operation or dressup, depending
on whether we mill "inside" or "outside", we now get the wrong results.
- In the (rarer) case of a reversed spindle direction, the "other half"
is wrong.
- Files created with previous versions of FreeCAD cannot be recomputed
any longer because there were no precautions on document restore.
- In files created with previous versions of FreeCAD one cannot change
the broken operation as the choices are now invalid.
- The original search/replace was incomplete.
- Only property values have been changed, the property names are still
inconsistent ("Direction" vs "Cutting Mode").
- The original search/replace also changed internal APIs where the
"climb"/"conventional" wording is not applicable as there is no
notation of "inside"/"outside" or "forward"/"reverse". If only the
path's direction is concerned, "CW"/"CCW" fits better.
