From 5c35c8b63a3d4239af2072b414a9e89a73990a34 Mon Sep 17 00:00:00 2001 From: dhkatz Date: Wed, 28 Oct 2026 05:22:28 -0700 Subject: [PATCH] Note the renderer process spike's results Co-Authored-By: Claude Opus 5.5 --- docs/architecture.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/architecture.md b/docs/architecture.md index 067ed10..3c92d40 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -36,9 +36,14 @@ client exits. ## Status A spike: the adapter still has IMVU's Direct3D 9 engine draw the scene (the pass-through), and the renderer process -only draws a box in the 3D view's corner, pulsing with the client's frames. It proves the risky parts: drawing into -the client's window from another process, keeping in step with the client's frames, and mouse input still reaching -the client. Next: the protocol carrying the frame's calls and resources, and the renderer process drawing the scene. +only draws a box in the 3D view's corner, pulsing with the client's frames. Checked in the client (Direct3D 11 in +software, on a machine without a graphics driver): the box draws over the scene from the 64-bit process, keeps in +step with the client's frames, clicks on it reach the scene, and each renderer process exits with its engine (room +changes) and with the client. The client keeps two engines alive in a room, so two processes (about 15 MB each); +one process serving all of a client's engines would be leaner. + +Next: the protocol carrying each frame's calls and the resources (buffers, textures), and the renderer process +drawing the scene itself, with IMVU's Direct3D engine left as the fallback. ## Building