From a021e2caa984980afe68e228703b39c43c31e572 Mon Sep 17 00:00:00 2001 From: dhkatz Date: Wed, 28 Oct 2026 18:47:29 -0700 Subject: [PATCH] Note the full view's speed on real hardware Co-Authored-By: Claude Opus 5.5 --- docs/architecture.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture.md b/docs/architecture.md index 5127f8e..19b1aab 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -64,9 +64,9 @@ For comparing while the client runs (development): be taken, and gives up on a renderer process that stops taking them (the client's renderer carries on). - The renderer process reproduces IMVU's Direct3D 9 setup (`renderer/shaders/fixed_function.hlsl`), particles included (point sprites, drawn as instanced squares), with a pipeline per combination of states. -- Speed: on a PC with a graphics card, a room frame takes about 2 ms to draw (some 430 draws), and the time from - the client finishing a frame to ours being presented is about 3 ms: the halves can't be told apart, even while - the camera moves. On the development VM (software rendering, over Remote Desktop) drawing takes 8 to 60 ms, and +- Speed: on a PC with a graphics card, drawing the whole view (3440x1059, a room of some 220 draws) takes 1.3 to + 3.8 ms a frame, and the time from the client finishing a frame to ours being presented is the same (frames don't + queue, none skipped). Earlier, in the split view, the halves couldn't be told apart, even while the camera moved. On the development VM (software rendering, over Remote Desktop) drawing takes 8 to 60 ms, and the right half visibly trails, mostly from compositing another process's window over Remote Desktop. The renderer process draws only the newest frame when it falls behind, and keeps at most one frame queued.