SeymourBETA

Update 2.19

6/6/2026

v2.19.0BETA

Seymour

Phase 2 of the plot twist: the SAME three.js viewer of the 816 models now runs INSIDE the editor window, in a panel — a new "Model Viewer (Embedded) 🐉" button in the Extras card → SetModule shows ModelViewerEmbedded_Control, which hosts an Edge WebView2 via NativeControlHost (win32 interop: child HWND + CoreWebView2Controller, bounds synced in ArrangeOverride, HiDPI via RenderScaling). It uses the already-installed WebView2 Evergreen runtime (no Chromium bundle — nuget Microsoft.Web.WebView2 1.0.2592.51, ~few MB; NOT the heavy CEF that would add ~100MB). The panel starts the same http server (ModelViewerLauncher.EnsureServerAndGetUrl, port 8767, cache-busted) and navigates the WebView to it; "Reload" + "Open in Browser" buttons (fallback). Program.cs/AppBuilder untouched. Build 0 errors. Proven in an isolated worktree spike (judged: compiles + 0 new warnings) before porting to main. Phase 1 (browser, v2.18.0) stays as a fallback. Owner decision alongside: the gallery opens at the clean REST pose (animation opt-in) — we stopped the offline animation whack-a-mole; real animation = mocap later (queued). Doc FFX_MODELVIEWER_EDITOR_2026-06-06.md

v2.18.1

v2.19.1BETA

Seymour

Direct answer to the owner ("the idea was ALWAYS inside the editor; opening a browser is dumb"): "Magic Viewer (Web)" stopped opening an external browser — the nav now SetModules the MagicViewerEmbedded_Control, a WebView2 panel inside the window. It reuses the SHARED WebView2Host the Model Viewer landed in v2.19.0 (one embedding infra for both viewers, no duplication). New MagicViewerEmbedded_Control/DataModel + MagicViewerLauncher.EnsureServerAndGetUrl (starts the local http server 8766 + cache-bust and navigates the WebView to it); Reload + Open in Browser (fallback) buttons. Coordination (2 chats on one branch): I waited for the other chat to commit WebView2Host (v2.19.0) so I could depend on it cleanly — no broken tree; their lane's code-audit findings are in HANDOFF_CODE_AUDIT_HD_MODELS_2026-06-06.md. Build 0 errors, editor relaunches without crash.

v2.19.0

v2.19.2BETA

Seymour

On screen the embedded WebView2 rendered in a corner only (~67% on a hiDPI display) with black margins, and didn't follow the editor size. Cause: SyncControllerBounds multiplied Bounds × RenderScaling while Avalonia ALSO sizes the host window → DPI double-counting (content at ~1/scale). Fixed in the shared WebView2Host (so it fixes Model Viewer v2.19.0 AND Magic Viewer v2.19.1 at once): size the WebView from the REAL parent client rect (GetParent+GetClientRect, no scale math) + re-sync on every resize (EffectiveViewportChanged + a deferred ArrangeOverride post at DispatcherPriority.Background so it runs after Avalonia repositions the native host). Build 0 errors. On-screen verify = owner's eye

v2.19.1

SeymourBETA

6/6/2026

v2.19.0BETA

Seymour

Phase 2 of the plot twist: the SAME three.js viewer of the 816 models now runs INSIDE the editor window, in a panel — a new "Model Viewer (Embedded) 🐉" button in the Extras card → SetModule shows ModelViewerEmbedded_Control, which hosts an Edge WebView2 via NativeControlHost (win32 interop: child HWND + CoreWebView2Controller, bounds synced in ArrangeOverride, HiDPI via RenderScaling). It uses the already-installed WebView2 Evergreen runtime (no Chromium bundle — nuget Microsoft.Web.WebView2 1.0.2592.51, ~few MB; NOT the heavy CEF that would add ~100MB). The panel starts the same http server (ModelViewerLauncher.EnsureServerAndGetUrl, port 8767, cache-busted) and navigates the WebView to it; "Reload" + "Open in Browser" buttons (fallback). Program.cs/AppBuilder untouched. Build 0 errors. Proven in an isolated worktree spike (judged: compiles + 0 new warnings) before porting to main. Phase 1 (browser, v2.18.0) stays as a fallback. Owner decision alongside: the gallery opens at the clean REST pose (animation opt-in) — we stopped the offline animation whack-a-mole; real animation = mocap later (queued). Doc FFX_MODELVIEWER_EDITOR_2026-06-06.md

v2.18.1

v2.19.1BETA

Seymour

Direct answer to the owner ("the idea was ALWAYS inside the editor; opening a browser is dumb"): "Magic Viewer (Web)" stopped opening an external browser — the nav now SetModules the MagicViewerEmbedded_Control, a WebView2 panel inside the window. It reuses the SHARED WebView2Host the Model Viewer landed in v2.19.0 (one embedding infra for both viewers, no duplication). New MagicViewerEmbedded_Control/DataModel + MagicViewerLauncher.EnsureServerAndGetUrl (starts the local http server 8766 + cache-bust and navigates the WebView to it); Reload + Open in Browser (fallback) buttons. Coordination (2 chats on one branch): I waited for the other chat to commit WebView2Host (v2.19.0) so I could depend on it cleanly — no broken tree; their lane's code-audit findings are in HANDOFF_CODE_AUDIT_HD_MODELS_2026-06-06.md. Build 0 errors, editor relaunches without crash.

v2.19.0

v2.19.2BETA

Seymour

On screen the embedded WebView2 rendered in a corner only (~67% on a hiDPI display) with black margins, and didn't follow the editor size. Cause: SyncControllerBounds multiplied Bounds × RenderScaling while Avalonia ALSO sizes the host window → DPI double-counting (content at ~1/scale). Fixed in the shared WebView2Host (so it fixes Model Viewer v2.19.0 AND Magic Viewer v2.19.1 at once): size the WebView from the REAL parent client rect (GetParent+GetClientRect, no scale math) + re-sync on every resize (EffectiveViewportChanged + a deferred ArrangeOverride post at DispatcherPriority.Background so it runs after Avalonia repositions the native host). Build 0 errors. On-screen verify = owner's eye

v2.19.1