[dancmari]

Fixes #592.

Step 1 reads trajectory and prediction vectors in the GUI while background odometry modifies or reallocates them. The sliding-window reset also clears bucket maps without taking the mutexes used by the renderer.

Keep the live trajectory, axis and prediction overlays using the existing WorkerData type and drawing functions. The producer copies only the displayed trajectory/prediction fields at safe pipeline boundaries, normally at most every 100 ms, with forced snapshots at initialization, pause and completion/failure. A mutex protects only the shared-pointer exchange; copying the display data and destroying the previous snapshot happen outside the lock. The GUI retains an immutable snapshot for each frame during processing and uses its original data while idle, so manual edits remain visible. Overlay toggles remain usable while paused.

Lock both bucket-map mutexes around the reset clear, and keep settings/gizmo editing disabled during the background run. The scope is limited to three existing Step 1 files. It adds no drawing structures, GPU buffers, maintained test targets or visual tests.

Validation:

• Windows Release x64 build and application startup passed.
• Existing Step 1 unit suite: 24 cases / 35 assertions passed.
• A local-only check compiled from the actual publisher implementation passed checks for snapshot ownership, selective field copying, throttling, forced refresh, coherent concurrent publication during source-vector replacement, retained-snapshot lifetime and reset to an empty recording.
• All three changed files pass clang-format 21.1.8 --dry-run --Werror. Existing worktree CRLF line endings are preserved.

The display snapshot introduces copying and RAM overhead. Live updates can lag while the worker is between safe publication points; no numerical speedup is claimed. Full-recording behavior, numerical output equivalence, ThreadSanitizer validation and Linux/macOS behavior still need validation. This PR addresses the identified trajectory display accesses and map reset; it is not a claim that every application threading issue is resolved.

[dancmari]

Somewhat faster processing, since previously, rendering would frequently keep the mutex required for calculations occupied. The change is significant for long-running processes.

[dancmari]

The latest commit separates the trajectory calculation data from the data used for rendering.
Previously, the interface would read the trajectories while the processing logic was modifying them. Now, the processing logic publishes consistent copies at safe intervals, and the interface renders them using reusable GPU buffers.
The primary improvement comes from fixing unsynchronized concurrent access. An additional benefit is the reduction in the need to rebuild and re-upload points, axes, and predictions for every frame.
Furthermore, this change will result in lower processing times during long sessions.

[michalpelka]

This is agentic coding results. I am fine with agentic coding, but I won't accept this PR in this form:

• it is large change,
• it introduce some tests, that are more than burden and test a features that could be tested by simply looking at output - I am not against TDD, but it seems that agent workflow dealing with UX things,
• it itroduces two things : race condition in step1 and UX improvement.

I recommend:

• issue for found UB,
• split PR to minimal fix for potential UB in step 1 (two - ten LOCs),
• larger PR that will reuse existing code for drawing, utilize raylib buffers.

[michalpelka]

Duplication of existing structure from codebase.

[michalpelka]

Raylib has its own strucutres for drawing lines with buffer.

[michalpelka]

I believe it is thought process of the agent not TDD.

[dancmari]

I’ve ruined all the charm. I’ll find a solution.

[michalpelka]

Let fix #592 with few mutexes than discuss what to add next. Step1's visualization is not essential, and meant to give operator early hint that LIO has exploded.

[michalpelka]

Thanks for refactor!