* perf: speed up startup and show progress in splash screen
Cold-start was ~15 s. Profiled in GUI_App::on_init_inner: 5 s in
preset_bundle->load_presets (sequential vendor loading of ~3000 JSON
profile files), 3.7 s in new MainFrame(), and a 1.5 s splash screen
that closed long before init finished — so the user stared at a
frozen blank screen for several seconds with no feedback.
Changes:
- PresetBundle::load_system_presets_from_json: parallelize vendor
loading with TBB. ORCA_FILAMENT_LIBRARY is loaded first
synchronously (it is the inheritance base for filaments); the
remaining vendors are loaded in parallel into separate PresetBundle
instances, then sequentially merged. On a typical setup this drops
load_presets from ~5 s to ~3.5 s; the saving scales with vendor
count and CPU cores.
- SplashScreen: remove the wxSPLASH_TIMEOUT flag so the splash stays
visible until the main window is shown explicitly, and add status
updates at each slow init phase ("Loading printer and filament
profiles", "Creating main window", "Loading current preset",
"Showing main window"). The splash is destroyed right after
mainframe->Show(true).
- MainFrame: FileHistory::LoadThumbnails moved to a detached
background thread. The previous synchronous call opened every recent
3MF file at startup — on macOS that triggered the TCC permission
dialog for ~/Downloads mid-launch, freezing the whole app until the
user clicked. Letting it run in the background means the UI is
responsive from the start and thumbnails populate when ready.
* revert: keep LoadThumbnails on the main thread (review feedback)
SoftFever pointed out the detached thread introduces race conditions
(e.g. MainFrame::open_recent_project() reading while the thread writes
m_thumbnails) and that thumbnails may not appear if the homepage shows
before it finishes. LoadThumbnails already uses tbb::parallel_for
internally, so the call-site offload gave no real speedup. Reverted to
the original synchronous call. The macOS TCC-dialog concern that
motivated this will be handled properly in the lazy-init refactor.
---------
Co-authored-by: SoftFever <softfeverever@gmail.com>
5a136a25d1