Previously it would just re-try all settings, but this really isn't needed (since
we have a setting relationship object that can tell us what settings depend on what).
This won't speed things up in a worst case scenario (since that will still be "caluclate
all the settings") but it will speed it up in most cases.
Most setting changes now only trigger a calculation that takes <0.2 sec isntead of the 1.1 sec.
Yes, those numbers seem big, but the error checking is already built in such a way that it spreads this
out over multiple frames (so it's not actually freezing that time, but it is doing shit it shouldn't do!)
CURA-7106
* Don't pre-load engine before other plug-ins
This was a fix for the post-processing plug-in that's no longer required.
It was also only applied when running from source, so obviously it's not required or we'd have seen it in the builds.
* Run automated tests in parallel
Done during Turbo Testing and Tooling.
* Pass number of processors via ctest command itself
More reliable apparently because it's a CMake variable that doesn't get cached. It shouldn't get cached or set in the CMake script because it's not the same for every computer.
Done during Turbo Testing and Tooling.
This was a fix for the post-processing plug-in that's no longer required.
It was also only applied when running from source, so obviously it's not required or we'd have seen it in the builds.
If Z hop is enabled, it would move to the height of the Z hop at the start of the print, in order to hop for the initial travel move. Cura sort of assumes that this hop is going up and so it's safe to do, but in reality this hop is going down due to the starting process in the firmware. As a hotfix, we'll just move away from that blob so that we don't hit it even if you enable Z hops.
The stacks would get marked dirty for setting some metadata, but since thats
part of their construction, they aren't really dirty.
Previously, every single stack that was loaded would be marked as dirty, which causes unneeded
saving.
