Mixed-colour slots are virtual and never flushed. Guard auto_calc_flushing_volumes_internal against them as BambuStudio does, and make the flushing dialog's default matrix and the sidebar 'modified' comparison physical-only so the untouched mixed rows no longer count as a user edit and the Re-calculate result matches the physical-only table.
* Add caching system for presets
* Removing user\bundle serialization and keeping it only for system presets
* Integrate caching into WebGuideDialog which speeds up time of SetupWizzard and PrinterSelection dialog
* Add CI\CD step to prepare cache file in ahead of time so user does not need to wait
* Add partial cache generation when only one of the vendros is changed to speed up recalculation time
* Handle corrupted files
* Add cache to GuideDialog as previos version didn't work as expected
* Add inspecting tool and fix CI cache generation
* Generate cache per vendor
* Simplify code by mergin it in PresetBundle
* Simplify code a bit more
* Add cereal serialize() to VendorProfile, PrinterModel, Preset, and Semver
* Remove CachedPrinterModel/VendorProfile/Preset mirror structs from VendorCache
* Fix use-after-free in CallAfter lambda; replace raw thread pointer with unique_ptr
* Use get_vendor_cache_key() to match cache keys written by the app
* Remove BOM added by VSC
* Skip invalid vendors
* Remove leftover cache file
* Fix build for windows arm64
* Revert json cache back
* Update check for stale cache
* Serealize all value fields for Preset class to minimize regression later
* Minimize field duplication by moving Cache thing into PresetBundle
* Add tests for Cache system
* Add a bit more tests
* Merge branch 'main' into feature/cache_profiles_and_optimize_loading_speed
* Rvert from per-verndor to single cache file
Replace N per-vendor .cache files with a single system_presets.cache
that holds all vendors and presets in one serialized blob.
Cache load is now all-or-nothing: on hit all vendors are applied from
the bundle (sub-second); on miss all vendors are parsed from JSON and
a fresh bundle is written to the user cache dir.
Invalidation is driven by bundle_key - a sorted concatenation of all
vendor JSON version strings. Any vendor update invalidates the whole
cache and triggers re-parse on next launch.
Guide wizard (WebGuideDialog) loads the bundled cache into a plain
PresetBundle instead of a separate VendorGuideData struct, removing
the duplicate data model.
generate_system_cache simplified from a per-vendor loop to a single
save_system_presets_cache() call producing one output file.
* Transfer all Preset fields from cache via move assignmet
apply_vendor_preset_group was copying fields manually and missed
bundle_id, user_id, base_id, sync_info, updated_time, key_values,
ini_str. Replace field-by-field copy with move assignment of the
fully-deserialized Preset, then restore the vendor pointer which
is excluded from serialization.
* Ignore cache for future
* Remove not used files
* Ship one preset cache per vendor in place of the profile JSONs
Each vendor's system presets serialize into a single <vendor>.opc built at
package time, and a shipped build carries that file alone — the profile JSON
and its sub-file tree are pruned. The vendor loader, the setup wizard's profile
list and the resource installer all read a vendor through its cache, falling
back to parsing whenever one is absent, stale or unreadable, so the cache stays
an optimization and never a source of truth. Caches hold presets in source form
and resolve inheritance at load, through the same code the JSON path uses.
* Make the preset cache self-describing and load each vendor from the system folder alone
The cached DynamicPrintConfig is keyed by name, through a per-file dictionary of the
distinct opt_keys, the type each was written as, and the distinct enum value names,
instead of by serialization_key_ordinal — a position assigned by declaration order at
static init, where inserting one option shifts every later ordinal and the lookup then
succeeds on the wrong option. Because a name-keyed payload drops the options this build
cannot place rather than being rejected wholesale, the schema fingerprint goes, and with
it the two fallbacks that existed only because an installed cache died on every app
upgrade: the second lookup tier into resources/profiles and the parse fallback to the
same place. A vendor is loaded from <data_dir>/system/ and nowhere else, as on main —
which is what makes the app write its .opc files there again.
* Simplify the preset cache internals after review
* Use the shared temp-dir helper in the preset bundle loading test
* Bound stamp string reads in the preset cache
* Speed up the setup wizard with a profile-data cache
The wizard's per-vendor fast path threw on vendors present only in
resources, falling back to a ~29 s raw JSON scan on every open. Each
vendor now loads from the directory it was found in, and the derived
model/machine/filament/process catalog is cached whole in
<data_dir>/cache/wizard_profile_data.json, stamped by each vendor's
name and version - a fresh cache makes an open one file read, with no
bundle built and no presets installed (~0.2 s vs ~2 s).
* Remove debug SVG dump from a geometry test
* Move the per-vendor cache file format into PresetCacheFormat
* Move the vendor install helpers from PresetBundle into Utils
* rename
* fix flatpak
* change cache version to 1
---------
Co-authored-by: SoftFever <softfeverever@gmail.com>
* Normalize the junction direction vector over XYZE
calc_vmax_junction_deviation() treats the dot product of two jd_unit_vec as a
cosine, but the vectors were scaled by 1 / block.distance, which is the XYZ
length. On an extruding move the E component then pushes the 4D norm above 1 and
the dot product below -1, so the corner reads as straighter than it is and is
planned too fast -- the more so the higher the flow. Measured on a 6 degree
corner at scv 5: 86.9mm/s with no extrusion, 94.4mm/s at 0.029mm/mm, 150.0mm/s
at 0.1mm/mm.
Neither firmware does that. Marlin normalizes over XYZE for any extruding move
(planner.cpp: `if (... || esteps > 0) normalize_junction_vector(unit_vec)`) and
Klipper leaves E out of the cosine entirely, dotting only axes_r[0..2]
(toolhead.py::Move.calc_junction). Normalizing satisfies both: with E normalized
in, the cosine differs from the XYZ-only one by ~1e-5 at printing flow rates.
This is a deliberate divergence from PrusaSlicer, which still scales by
1 / distance -- it carries an older Marlin's behaviour.
Travel moves are unaffected, their vector was already unit length.
Reported by Copilot in review of #15304.
* Test that extrusion rate does not change corner planning
The junction deviation tests were all travel-only, which is exactly why the E
component of the junction vector went unchecked. Cover it: the same corner has
to be planned the same whether nothing, an ordinary 0.42 x 0.2 line, or a fat
large-nozzle line is extruded through it, on both Klipper and Marlin 2.
Reported by Copilot in review of #15304.
* Plan corners with junction deviation where the firmware uses it
The time estimator only ever had the classic per-axis jerk model, which limits a
corner by the largest single-axis component of the velocity change. That is
anisotropic: the same corner is allowed sqrt(2) more speed on a diagonal than on
an axis, which paints a four-lobed ripple around every circular wall in the
actual speed and actual flow views, worst on small parts whose walls are made of
short segments.
Klipper has no classic jerk at all and Marlin 2 has none while M205 J is in use;
both plan corners with junction deviation, which sees only the corner angle. Add
that model and use it for those machines:
- Klipper: derived from the square corner velocity, as the firmware does
(jd = scv^2 * (sqrt(2) - 1) / max_accel), reading the scv from
machine_max_jerk_x, where process_SET_VELOCITY_LIMIT() already stores
SQUARE_CORNER_VELOCITY.
- Marlin 2: machine_max_junction_deviation, which was already loaded into the
machine limits but never reached the planner.
- Every other flavor keeps the classic jerk path unchanged.
The model has no per-axis jerk floor, so this also drops the hard slow spot the
estimator drew at the start of every loop from machine_max_jerk_e.
Toolpaths are unaffected: on a full export the only lines that change are M73.
The junction deviation maths, including Marlin's JD_HANDLE_SMALL_SEGMENTS arc
approximation, is ported from PrusaSlicer's src/libslic3r/GCode/GCodeProcessor.cpp.
The Klipper mapping is not in PrusaSlicer, which ignores SET_VELOCITY_LIMIT.
* Add tests for junction deviation corner planning
Cover the three properties the change rests on:
- a right angle on Klipper is planned at exactly the square corner velocity,
the identity that makes the scv to junction deviation mapping correct, and a
shallow corner is planned far faster than per-axis jerk allows;
- junction deviation gives the same speed whatever the corner's orientation,
while classic jerk keeps its sqrt(2) spread, which is the four-lobed ripple;
- machines that do not plan with junction deviation are provably untouched,
including a Marlin 2 printer that has it disabled.
# Description
Printers discovered/bound under one printer agent (e.g. built-in BBL)
were leaking into another, independent agent's "My Device"/"Other
Device" lists and inheriting its saved access code, since neither the
device list nor bind state was ever scoped by which agent found them.
- Add printer_agent_id to MachineObject/BBLocalMachine, stamped at
discovery/bind time; filter get_my_machine_list(),
get_my_cloud_machine_list(), and update_other_devices() by it.
- clear_other_devices() now drops entries stamped by the outgoing
agent on swap, so the incoming agent's own discovery re-inserts and
re-stamps them fresh instead of leaving them stale-tagged forever.
- Scope access_code by (dev_id, printer_agent_id) on BBLocalMachine
(LAN only since cloud's userMachineList is always refreshed live from
the account API, so it isn't at risk the same way), with a
BBL-only legacy fallback to the old flat access_code/user_access_code
keys so existing bindings keep working.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
# Description
Break the recursive include dependency by moving GUI_App.hpp from
HMS.hpp into HMS.cpp. Add the required standard headers and use explicit
std/nlohmann types to remove reliance on transitive includes.
This prevents recursive header inclusion while preserving HMS
functionality.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
# Description
This PR enables building OrcaSlicer on Windows with the **clang-cl
(LLVM)**
toolchain and the **Ninja** generator, in addition to the existing MSVC
path.
Clang is already supported on Linux with this codebase, so this extends
that
support to Windows.
The changes fall into three categories. All are either no-ops on the
existing
MSVC/Visual Studio path or Windows/clang-cl-specific, so the standard
build is
not affected.
### 1. C++ conformance fixes
clang-cl is stricter than MSVC and rejects several constructs that
cl.exe
silently accepted. Each of these is non-conforming code that MSVC
tolerated:
* **Explicit template instantiation in `BoundingBox.cpp`** — clang-cl
does not
instantiate `BoundingBoxBase<Point, Points>::construct` through the same
transitive path MSVC uses; added the explicit instantiation.
* **Eigen cast materialization in `AABBTreeLines.hpp`** — `.cast<T>()`
returns a
lazy `CwiseUnaryOp`, not a concrete `Matrix`; materialized it before
passing to
`distance_to_squared`, which expects a concrete type.
* **`LabelItemType` underlying type in `PresetComboBoxes.hpp`** — gave
the enum
the same `std::size_t` underlying type as `Marker` to resolve a
narrowing
conversion in a switch.
* **`T2A_` cast in `BaseException.cpp`** — explicit `static_cast<const
char*>` on
the ATL conversion helper result.
* **Wide string literals in `GUI_App.cpp`** — used `L""` literals where
concatenated with a `std::wstring` (`url_prefix`).
### 2. Build system / dependencies
* **Exclude clang-cl from MSVC-only CMake guards** — `if(MSVC)` is true
for
clang-cl, so blocks applying cl.exe-only flags now exclude Clang.
* **Disable TBB LTCG** — oneTBB enables MSVC IPO/LTCG by default,
emitting
proprietary `/GL` bitcode objects that `lld-link` cannot consume.
Disabling IPO
produces native COFF, linkable by both `link.exe` and `lld-link`. TBB is
threading infrastructure, so the runtime impact of disabling LTCG is
negligible.
* **wxWidgets target path** — clang-cl uses the MSVC frontend variant on
Windows
but reports compiler id `Clang`, so wxWidgets looked under
`clang_x64_lib`
instead of the `vc_x64_lib` layout the deps are built with.
### 3. Ninja generator support
* **Runtime DLL copy** — the DLL copy step was nested under
`CMAKE_CONFIGURATION_TYPES` (multi-config only), so single-config Ninja
skipped
copying OCCT/GMP/MPFR/WebView2/freetype DLLs next to the executable. Now
runs
for both generator styles, guarded by `if(WIN32)`.
* **`build_release_vs.bat` Ninja target** — `ALL_BUILD` is a Visual
Studio
target; Ninja uses `all`. The script failed with
`ninja: error: unknown target 'ALL_BUILD'` when invoked with `-x`.
## Tests
Built from a clean checkout on Windows with:
* clang-cl 22 (LLVM toolchain bundled with Visual Studio 18)
* Ninja Multi-Config generator
* lld-link as the linker
The full build (deps + slicer) compiles, `OrcaSlicer.dll` links with
`lld-link`,
and `orca-slicer.exe` runs. Verified end-to-end by loading a model,
slicing it,
and generating valid G-code (screenshot below).
The existing MSVC / Visual Studio build path is unaffected — all changes
are
guarded by compiler/generator/platform checks or are conformance fixes
that
compile identically under MSVC.
# Screenshots
<img width="1919" height="1079" alt="image"
src="https://github.com/user-attachments/assets/02082437-db36-4696-a91a-d9acf57d4a52"
/>
