Never make the client wait for drawing, or hold up its steps

The renderer process now takes each view's chunks on a thread of its own as
they come, and draws the newest frame on its main thread: the client no longer
waits for the previous frame to be drawn (on a VM, 22 of a frame's 25 ms).

The adapter records the client's steps (SceneViewer::step, by replacing its
entry in the exported IFrameListener vtable, after checking it), and the frame
pacer doesn't ask for a frame that wouldn't end before the next step is due: a
late step made the client catch up two at once, which showed as hitches. While
the renderer process covers the view, the client's renderer doesn't begin or
present frames, which could wait for the display.

The engine's stats now include the time in the client renderer's methods.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/architecture.md

@@ -83,8 +83,15 @@ data area (16 MB: the client's 2048x2048 snapshots just do). Checked with outfit
 Higher frame rates (in progress): the client steps its scene 30 times a second (SceneWindow.dll's `runApp`), and
 draws a window's frame on WM_PAINT. The adapter's frame pacer (`adapter/frame_pacer.cpp`) asks the 3D windows to
 repaint between steps at the user's rate (T5DE's settings, Graphics: `HKCU\Software\T5DE\Graphics\FrameRate`), only
-when affordable: drawing shares the client's main thread with its input and interface. The extra frames show the
-same scene until animations, the camera and particles are drawn at the time between steps.
+leaving the client idle time, and never holding up the next step: the adapter records the client's steps by replacing
+`SceneViewer::step`'s entry in its exported vtable (`adapter/scene_hooks.cpp`, after checking it), and a frame that
+wouldn't end before the step is due isn't asked for (a late step makes the client catch up two at once: hitches).
+While the renderer process covers the view, the client's renderer doesn't begin or present frames (its present can
+wait for the display). The renderer process takes each view's chunks on a thread of its own as they come, so the
+client never waits for drawing; it draws the newest frame. On a PC with a graphics card a room frame takes the client
+about 2.5 ms (the client's own work: posing avatars, which it does every frame, and walking the scene), and the
+renderer process about 0.5 ms. The extra frames show the same scene until animations, the camera and particles are
+drawn at the time between steps.
 
 Next: sharing pipelines between views (each view's scene compiles its own).