WIP to G-code export parallelization through pipelining:
Decoupled CoolingBuffer from GCode / GCodeWriter, ready to be
pipelined on a different thread.
Delete () function did not account for InfoItems that were added before VolumeItems
As a result, There was possibility when deletion of penult VolumeItem wasn't invoke deletion of the last VolumeItem
AddInfoChild() was not respect to existed SettingsItem
SettingsItem have to be on a first place always.
Steps to repro:
1. Create some object with several parts.
2. Increase instances count.
3. Select some volume in ObjectList => all related volumes for each instance are selected in 3DScene (CORRECT)
4. Select last instance in ObjectList => all volumes (except one) of selected instance are selected in 3DScene (UNCORRECT).
ALL volumes of selected instance have to be selected in 3DScene
Fix: To avoid lost of some volumes in selection
check non-selected volumes only if 3DScene-selection mode wasn't changed
or there is no single selection in ObjectList
WIP to G-code export parallelization through pipelining:
GCodeProcessor is called during the G-code export,
the G-code is no more reopened and re-read, but it is pipelined
from the G-code generator.
GCodeViewer no more parses G-code just to extract line end positions.
Removed start_mapping_gcode_window(), void stop_mapping_gcode_window(),
they are no more needed.
The old version of GCC and Clang support only integers to be passed to std::to_chars and std::from_chars. macOS older version of Clang doesn't support std::from_chars at all. So for Linux and macOS, it was replaced std::from_chars with strtod and temporarily was replace std::to_chars with snprintf.
This was broken between 2.2.0 and 2.3.0. The 'entering' snapshot
should be taken before the gizmo opens, not after. Otherwise it is
in fact the same as the next snapshot.
This is a regression to a late PrusaSlicer 2.4.0-alpha0 change
8dfc0422a8
Faster and hopefully more reliable projection of paint-on support
blockers and enforcers on a sliced mesh.
Previous d89f01c717 did not fix it.
This is a regression to a late PrusaSlicer 2.4.0-alpha0 change
8dfc0422a8
Faster and hopefully more reliable projection of paint-on support
blockers and enforcers on a sliced mesh.
../src/libslic3r/QuadricEdgeCollapse.cpp:628:21: warning: comparison of integer expressions of different signedness: 'const int' and 'uint32_t' {aka 'unsigned int'} [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:631:21: warning: comparison of integer expressions of different signedness: 'const int' and 'uint32_t' {aka 'unsigned int'} [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:638:48: warning: comparison of integer expressions of different signedness: 'const int' and 'uint32_t' {aka 'unsigned int'} [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:643:25: warning: comparison of integer expressions of different signedness: 'const int' and 'uint32_t' {aka 'unsigned int'} [-Wsign-compare]
../src/libslic3r/QuadricEdgeCollapse.cpp:647:25: warning: comparison of integer expressions of different signedness: 'const int' and 'uint32_t' {aka 'unsigned int'} [-Wsign-compare]
1) Activate installed filament or SLA material profile after update_compatible(),
so that the compatiblity and visibility flags of presets are updated.
2) Only activate the first newly installed filament / SLA material profile
if the active printer did not change. This also means that if no filament
profile was active before Wizard was open or it became incompatible with
the newly installed Printer profile, the default filament profile assigned
to the activated Printer is activated preferably, which may or may not
be one of the newly installed filament profiles.
object layer over raft interface:
"first_layer_speed_over_raft", "first_layer_acceleration_over_raft".
Fixes I have a question about the speed of the first layer after the raft. #6623
Fixes Layer After Raft Is Not Considered First Layer! #6166
1) Changed the name of the variable "brim_offset" to "brim_separation"
for clarity.
2) Added legacy conversion after loading an old 3MF that does not define
then new "brim_separation" variable: The "brim_separation" is being
filled in with the "elefant_foot_compensation" value to produce
equal brim separation to the old PrusaSlicer that saved that 3MF file.
reset timestamp to 1. This led to a bug where e.g. deleting painted facets
through the respective item in object list followed by possible other actions
and undo restored the painted facets from the time when the project was loaded.
I'm not sure if there was any other situation where this problem manifested.
