load_vendors merged each vendor's bundle into the startup bundle in turn,
inserting every preset at its sorted place in a deque, so each insert shifted
every preset after it.
PresetBundle::merge_presets now takes every loaded bundle at once, and each
collection merges its sorted presets with theirs in one pass. A preset name this
bundle or an earlier one of the list already has is still left out and reported
under the vendor that repeats it, in the same order as before.
Installing a vendor's filaments looks up the filament library, so load_vendors
loads the library first. Reading a vendor, from its cache or its JSONs, needs
nothing from the library, yet every other vendor waited for it before starting.
load_vendor_configs_from_json splits into read_vendor and install_vendor_read.
load_vendors reads the other vendors in parallel while the library loads, and
installs each against it as soon as both its read and the library are done. A
cache the library can no longer install is still replaced by a parse of the
vendor's JSONs, now when it installs; a canceled load is not mistaken for such
a cache. Vendors start costliest first, and a cache older than the profile
beside it is ordered as a parse.
load_vendors also names the vendors that failed, the library included, which
keeps what it installed before failing and so stays among the bundle's vendors.
The setup wizard falls back to its own scan on that list rather than on which
vendors the bundle holds.
A vendor keeps a copy of each config its other entries inherit, and the filament
library keeps every one of them for the vendors that inherit from it. The copy
was made in commit, one entry at a time on the calling thread while the workers
waited, and the library alone makes 960 of them.
Whether an entry's config is kept depends only on names known before any entry
resolves, so resolve_vendor_preset makes the copy alongside the rest of its work
and commit moves it in.
When the wizard's profile-data cache is stale, which any vendor's version change
makes it, the printer and filament selection dialogs rebuild it by loading every
shipped vendor, 66 of them here, one after another. Startup loads its vendors in
parallel once the filament library is in.
That step moves out of load_system_presets_from_json into
PresetBundle::load_vendors, which takes each vendor with the directory it is
installed in, and the wizard calls it too. A vendor that fails to load still
sends the wizard to its hand-written JSON scan, as the exception it used to throw
did, now once the others have loaded and with the error logged. merge_presets
goes private, since the wizard no longer merges bundles itself.
Opening either dialog with a stale cache goes from 3.38-3.55 s to 2.33-2.47 s on
a 16-core desktop, and the vendor rebuild inside it from 2.34-2.48 s to
1.27-1.41 s. The catalog it writes is byte-identical to the one main writes, and
a dump of every preset startup loads is unchanged.
A cache load installed the entries others inherit from or include first and
resolved the rest together, while the JSON parse installed each entry straight
after parsing it. The two orders only agree while every preset is listed after
what it depends on. An include listed after the preset naming it was missing for
one and found by the other, and every new kind of reference between presets
would have needed the same care in two places.
Both loads now go through install_vendor, which installs processes, filaments and
printers in listing order. Entries resolve together in runs and commit one at a
time, and a run ends before an entry that inherits or includes one already in
it. No entry resolves against a registration from its own run, so the result is
what installing one at a time gives, in any listing order.
The JSON parse reads every sub-file first, under one numeric locale setter, and
stops at the first that fails. The ones before it are installed before the
failure is raised, as they were one at a time, and the filament library's maps
are published only from a complete load. Each entry's parse errors are logged and
counted when it installs, so the log and a load that fails partway come out as
one-at-a-time loading leaves them.
Every preset already in the collection counts as taken for a new one's name.
resolve_vendor_preset and commit_vendor_preset take a VendorInstall with the
collection's shared state in place of a dozen parameters, const for resolve.
The first launch after an update, which parses every profile, goes from
1510-1533 ms to 806-849 ms on a 16-core desktop, and a cached launch from
342-357 ms to 328-334 ms.
Every preset of the filament library keeps its config for other vendors to
inherit from, and publishing that map copied all 1281 of them. The map it is
built in is cleared by the next install before anything reads it again, so the
copy was of no use to anyone.
Loading the library goes from 145 to 86 ms, and the whole preset load from 360
to 300 ms.
Installing a preset placed it at its position in the sorted collection, which
moves every preset after it, so a vendor with 2528 filaments paid an O(n)
insertion 2528 times. That is serial work at the end of a load whose per-preset
part now runs across threads, so it is what the load waits on.
The entries are appended and the collection sorted once they are all in, the way
user presets are already loaded. The sort is on a scope guard, so it also runs
for an entry that cannot be installed and throws past the end of the loop. A
repeated name was caught by find_preset against the half-filled collection,
which an unsorted one cannot answer, so the names are kept in a set, seeded with
the default presets that are in the collection before the first entry arrives.
A preset's config is a copy of the one it inherits with the entry's diff applied
over it, so the only keys it can hold that the parent does not define are the
ones in that diff. Scanning all of them instead walked 141 keys per filament
preset where 23 would do, and built a vector of every key's name to do it.
The keys the caller knows were added are checked where it has them, and the scan
of everything stays for the callers that do not. An entry that includes a
template is checked the same way, since an include diff holds only keys of the
collection default. The check also moves above Preset::normalize, which derives
keys from the ones it finds. A key derived from one the profile should not have
carried is in neither the diff nor the parent, so after normalize nothing would
name it.
A user preset is read from its own file and flattened against the system preset
it inherits. It cannot inherit another file of the same pass, because the presets
being read only join the collection once they have all been read, so the files
are independent of each other.
load_presets splits the way the vendor cache load already does:
resolve_user_preset reads and flattens one file and touches nothing shared, and
commit_user_preset installs it, counts its errors, and does the file work a load
can trigger (removing an unreadable preset, writing back a filament preset that
named no compatible printer). Both callers now share resolve_then_commit, which
holds the two-phase shape, works through the items in batches so what is held at
once does not grow with how many there are, and gives each piece of a batch one
CNumericLocalesSetter rather than one per file. It throws rather than commit a
batch that a canceled task group of the caller left unresolved.
A setter nested in another on the same thread does nothing while the locale is
still "C", so one setter per piece of a batch covers every file in it, and each
batch runs isolated, so a thread waiting on it picks up none of the caller's
other work. A filament preset whose derived compatible printer cannot be written
back still loads, with the failure counted.
Loading 328 user presets goes from 105 to 34 ms on a 16-core desktop.
Reading one preset file tries a dozen key names against every key in it with
boost::iequals, which compares through std::locale(). Constructing that takes a
lock the whole process shares in the MSVC runtime, so it is both the bulk of the
work in a preset file's parse and the reason two threads cannot do it at once.
Comparing the bytes instead takes loading 328 user presets from 129 to 105 ms
one at a time, and the same files spread across threads from 132 to 27 ms. The
first launch after an update, when the system profiles are parsed from JSON
rather than served from their cache, goes through the same function.
Installing one entry is a config copy, the entry's diff applied over it,
normalization and an invalid-key scan. For the largest vendor that is around
2000 filaments at about 115 us each, and all of it reads state that does not
change while the collection loads.
load_vendor_preset splits into resolve_vendor_preset, which flattens an entry
and touches nothing shared, and commit_vendor_preset, which installs it. A
cache load installs the entries others inherit from first, since what those
register is what the rest resolve against, then resolves the rest together and
commits them one at a time. The JSON parse calls the two back to back as before.
On a 16-core desktop with 4263 system presets installed, preset loading goes
from 644-652 ms to 370-376 ms, and a bundle loaded either way comes out
identical, preset for preset and option for option.
The parallel_for over the vendors used an auto_partitioner, which splits its
range only while a worker is asking for work. At six vendors that often did not
happen at all. In two runs out of four on this machine every vendor in that step
ran on the calling thread, which the log shows as one thread id for all of them.
A grain of one splits the range up front. The vendors also start slowest first,
so the vendor that decides when the step ends is not the one left until last. A
vendor with no cache is parsed from its JSONs, which costs far more than any
cache load, so those go before cached ones, and within each group the bigger
file goes first, the cache or the profile index that names the vendor's presets.
get_dpi_for_window's pre-8.1 fallback and get_font_list_by_enumeration
both called GetDC without a matching ReleaseDC, leaking a GDI handle
each call. get_dpi_for_window runs on every mouse-move over the 3D
viewport, so the leak exhausts the per-process GDI handle limit and
hangs the app within minutes on Windows 7/8.
Co-authored-by: Fernando Marino <f.marino@rheagroup.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
The OFL OTA workflow sent an ISO-8601 timestamp to the pending-clear
endpoint, which only accepts Unix epoch seconds. This caused the
scheduled workflow to fail with HTTP 400.
Use `data -u +%s` so that request matches the endpoint contract.
# 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
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
If a vendor runs `/bot merge` while the cronjob is running, it might be
dropped because the table might be cleared before `post_merge_profiles`
completes. Instead we can add a timestamp so that we don't accidentally
drop any PR merges that occur while the OFL cronjob is running.
# 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
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
The previous implementation checks against the last successful
`post_merge_profiles` which can trigger when a normal OTA update for
non-OFL profiles are made. This causes the check to fail when OFL
changes are made before other regular profile changes are made in
`resources/profiles/<vendor>`
# 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)
Merged by /bot merge on behalf of @peachismomo (id 52488812).
Grants: resources/profiles/OrcaFilamentLibrary/filament/Elegoo, resources/profiles/OrcaFilamentLibrary.json, resources/profiles/Elegoo, resources/profiles/Elegoo.json
Head: b73e9df4f4
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
- `OrcaFilamentLibrary` (OFL) has no `FOLDER_MERGERS` delegation and
changes far more often than other vendors, so it can't go through the
existing merge-triggered, human-published OTA flow.
`post_merge_profiles.yml` gains an explicit `vendor` + `auto_publish`
`workflow_dispatch` path that bypasses the `FOLDER_MERGERS` check and
calls the OTA auto-publish API directly, making the update live with no
human step.
- `ofl-ota-cronjob.yml` drives that path daily across `main` and every
`release/vX.Y.Z` branch, checkpointed against
`post_merge_profiles.yml`'s own per-branch run history so a failed
publish is retried rather than silently dropped.
- Fixes a pre-existing bug in `post_merge_profiles.yml`: a single vendor
with no `FOLDER_MERGERS` grant in a push used to zero out the *entire*
vendor batch, silently dropping other, properly-authorized vendors'
publishes too. It now drops only the ungranted vendor, with a warning.
## Notes
Once v2.5.0 stable is released, we need to remove branch checking
against main in both these workflows.
# 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 brings back the Bambu Lab profile sync with BambuStudio, reverted
from main, along with its bed-model offset fix. The synced printers and
filaments share their start and end G-code and dual-nozzle settings
through template files that Orca did not read, so those printers had no
machine G-code. Orca now loads these templates the same way BambuStudio
does, so every synced preset comes in complete. `profile_include_dump`,
a new developer tool, compares the result with BambuStudio's.
Other vendors' profiles are unaffected. Bambu Lab profiles move to
version 02.08.00.10, so installs that took the earlier sync update too.
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
## Tests
Unit tests cover how template settings combine with inherited and preset
settings, loaded from JSON and from the preset cache. The profile
validator passes on every shipped vendor, and every Bambu Lab preset
gets the same template values in Orca as in BambuStudio.
<!--
> 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)
A scarf joint split the loop at exactly the scarf length, so the remainder
of the segment the split landed in became the first flat segment, often a
fraction of a millimetre. The seam insertion also leaves segments of a few
micrometres at both ends of the loop, which a scarf extrudes through where a
plain loop would start or stop. With junction deviation the planner treats
such short moves as tight corners, limited by the Z axis acceleration at the
end of the ramp, and slows to a third of the wall speed or nearly halts at
the seam.
Extend the ramp to the next vertex when the remainder would be shorter than
half a scarf step, capped at a millimetre, beyond which planners treat a move
as ordinary; the scarf only grows, never shrinks. Drop the vertex next to the
seam point at either end when that segment is shorter than an eighth of a
common line width, so the loop still starts and ends at the seam; a trimmed
path loses its arc fitting and prints as line segments. Clamp the scarf
length to the trimmed loop so a scarf covering a whole loop still ends at
full flow. The descending pass reuses the same path, so both wedges stay
consistent, and a flat part that would collapse to a single point is dropped.
The global arrange branch, taken by --arrange with all plates selected, only
reserved the prime tower when filament ids had been given on the command
line for STL input. A project carries its filament use per plate and its own
tower positions, but that set was empty for it, so the tower was never an
obstacle: the arranged pile was centred over it and the slice then failed on
a G-code path conflict.
When no filament ids were given, count the filaments each plate uses and
reserve a tower on every plate that needs one, keeping the project's tower
position instead of resetting it to the default. Only a tower the slicer will
print is reserved: the prime tower must be enabled, and a by-object print
gets none unless a smooth timelapse needs it, as the per-plate arrange
decides. Overflow beds are sized for the busiest plate. The STL route is
unchanged.
G-code generation collects errors raised per object, such as an empty
first layer, into one SlicingErrors exception whose own message is just
"Errors". The CLI's generic handler printed that word and recorded the
generic slicing error text, so a headless caller had nothing to act on.
Let Print render the per-object messages with each object's name, and have
the CLI catch SlicingErrors ahead of the generic handler, print that text
and record it as the result's error string. The exit code is unchanged. A
unit test lifts a cube off the bed and checks the message names the object.
Since #15811 the settings page is built when its tab is shown, so on a
Home start that opens a project the Quality page is built on screen. Its
flow-compensation-model field is a multiline text view that GTK maps as
it is created and that is hidden, because compensation is off, before
GTK first allocates it. The loading dialog's wxWindowDisabler then
desensitizes the frame, and GTK crashes in
gtk_text_layout_cursors_changed() on that text view.
On GTK the page view is now hidden while a page is built, so a control
that starts hidden is never realized and GTK realizes it when it is
shown. The deferred build is unchanged.
For clang-cl, CMake sets the depfile flags to the gcc-style -MD, -MT and -MF,
passed through as -clang: arguments. ccache does not parse those, so a cache
hit writes only the object. Ninja has no depfile to read, so it records zero
header dependencies for that object and does not rebuild it after a header
edit. The stale object is still linked into the library and the DLL. sccache
0.15.0 reproduces the depfile on a hit and is unaffected.
Use /showIncludes instead. CMake already does that for MSVC, and ccache
reproduces it on a hit. A make-rules override sets the flags, because CMake
includes the override after Platform/Windows-Clang.cmake. It is forwarded to
each dependency because every one configures as its own CMake project, and it
is only set when the file exists, because scripts/flatpak/make_deps_tar.sh
packs deps/ alone.
In a build with a warm cache, 678 of 790 objects had no recorded headers.
Object code does not change. One GUI translation unit compiled both ways is
byte-identical apart from the COFF timestamp.
* preset updater: refresh installed vendors from resources regardless of enable_ota
Since c4fea8ad24 the resources check in check_installed_vendor_profiles()
sat behind enabled_config_update, which now follows enable_ota, a hidden
flag that defaults to off. The hotfix a93c6ea67b then made that gate skip
installed vendors entirely, so a new build's newer vendor profiles were
never installed over an existing vendor unless OTA had been turned on.
Before the gating the update URL always had a default, so the comparison
effectively always ran.
The resources shipped with a build are not an over-the-air update. Judge
installed vendors against them, and drop the ones no longer enabled,
regardless of the flag; enable_ota keeps gating the online sync.
* preset updater: stop reinstalling the filament library on every launch
check_installed_vendor_profiles() put OrcaFilamentLibrary on the install
list unconditionally, so every launch recopied the whole vendor from
resources and, in a build that ships the profile JSONs rather than a
preset cache, then re-parsed and re-cached it: about 0.3 s of a dev
build's startup, and a 3 MB copy in a release build, for a vendor that
had not changed.
The library was special-cased because it is never in the enabled-vendor
list. Treat it like the default bundle instead: always wanted, and
reinstalled only when the resources carry a newer version.
raistlin7447