Own preview and recording workers

This commit is contained in:
2026-06-16 07:18:08 +02:00
parent 4d7a23a1fd
commit 3366b54c7f
8 changed files with 78 additions and 51 deletions

File diff suppressed because one or more lines are too long

View File

@@ -106,9 +106,9 @@ Current architecture mismatches that must be treated as real blockers:
- `app_layout.cpp` and `app_dialogs.cpp` are still mixed shell/controller files
rather than thin composition/binding surfaces.
- `App`, `Canvas`, `Node`, retained workers, and platform entrypoints still use
global singleton reach, raw observer pointers, detached `std::thread`
launches in preview/recording paths, and ad hoc
mutex/condition-variable ownership.
global singleton reach, raw observer pointers, retained static worker
ownership in several app families, and ad hoc mutex/condition-variable
ownership.
- Modern C++23 usage exists in extracted components, especially `std::span`,
explicit result/status objects, and a few concepts, but the live app still
does not consistently express ownership, thread affinity, or renderer

View File

@@ -49,7 +49,9 @@ Completed, blocked, and superseded task history moved to
- `platform_legacy` is still part of the live app shell
- The app runtime boundary is not finished:
- render/UI queues are static `App` state
- detached workers still launch from preview and recording code
- app-facing detached launches are no longer the main issue; preview and
recording now use owned worker threads, but those families still rely on
retained static/global ownership and ad hoc runtime control
- canvas async import/export/save/open now run through an owned in-file
worker, but their retained progress execution is still not a clean runtime
service boundary
@@ -359,7 +361,8 @@ Current slice:
workers with explicit UI-thread handoff
- canvas async import/export/save/open and timelapse export now also use owned
worker queues instead of detached threads
- preview and recording-side detached work are still open
- preview background rendering and recording thread ownership now also use
`std::jthread`, but their retained loop/control flow is still open
Write scope:
- `src/canvas.cpp`