Draw render targets in the renderer process

While the renderer process runs, the adapter makes the client's render targets
itself and the renderer process draws frames into them: texture targets are
drawn with like any texture, and a pixmap target's frame is read back through
the channel into its Pixmap (protocol version 4: BeginFrame names its target,
CreateRenderTarget, Channel::readSize and the -read event). Frames into render
targets are drawn even while the window is hidden.

The client uses pixmap targets for snapshots (outfit pictures, photos), checked
to look right. The render target interfaces are declared from IMVU's vtables.

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

docs/architecture.md

@@ -39,8 +39,8 @@ The process exits when the engine is destroyed or the client exits.
 ## Status
 
 The renderer process draws the whole 3D view in place of the client's renderer (the full view, the default). The
-adapter still forwards everything to the client's Direct3D renderer (state and resources: it draws render targets and
-reads textures back, which the renderer process doesn't yet), but while the renderer process covers the whole view
+adapter still forwards state and resources to the client's Direct3D renderer (as a fallback, and for reading textures
+back, which the renderer process doesn't do), but while the renderer process covers the whole view
 (`Channel::covering`, set after each frame it presents) the client's renderer skips its clears and draws, decided per
 frame; it draws again as soon as the renderer process stops covering the view (the view changes, or the process
 fails). Checked in rooms with screenshots of both renderers side by side (the compare view): they match, particles
@@ -70,8 +70,13 @@ For comparing while the client runs (development):
   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.
 
-Next: render targets (offscreen frames are skipped, and drawn by the client's renderer), and one renderer process for
-all of a client's views.
+Render targets are the renderer process's too, while it runs: the adapter makes its own (`PixmapTarget`,
+`TextureTarget`), the renderer process draws frames into them (textures in the window's formats, so the same
+pipelines draw both), and a pixmap target's frame is read back through the channel (`Channel::readSize`, the
+`-read` event) into its Pixmap, as the client's renderer does, synchronously. A read back must fit in the channel's
+data area (16 MB: the client's 2048x2048 snapshots just do). Checked with outfit pictures and photos.
+
+Next: one renderer process for all of a client's views.
 
 ## Building
 

docs/interface.md

@@ -83,8 +83,14 @@ virtual methods, IMVU's code only uses an engine through helpers that call its v
   practice: clamped to it they look much smaller and fainter than the client's.
 - Fog: linear table fog, start 1 and end 50 in rooms. Fogging by view depth matches the client; by depth buffer
   value (as Direct3D 9's documentation suggests for projections like IMVU's) doesn't.
-- Still unknown: render targets, `CompoundRegion` (texture update
-  regions), `newRenderTexture`'s flags, and what `beginRendering` does with a null target. MSVC orders overloaded
+- Render targets (`include/t5de/imvu/resources.hpp`): the engine returns each as a pointer into its own object;
+  the client calls only their interfaces' methods and passes them to `beginRendering`. A pixmap render target has one
+  method, `getPixmap()` (a Pixmap returned by value), with the pixels of the last frame drawn into it (IMVU's engine
+  copies them from the GPU at the frame's end). A texture render target has `area()` (always 0, 0, 1, 1) and
+  `texture()` (a new texture object for what's been drawn, as a shared pointer returned by value). The client uses
+  pixmap targets for snapshots (`takeSnapshot`: outfit pictures, the photo widget), 2048x2048; texture targets
+  haven't been seen used. Pixmap is 28 bytes; pixmap.dll exports its constructors and destructor.
+- Still unknown: `CompoundRegion` (texture update regions), `newRenderTexture`'s flags, and what `beginRendering` does with a null target. MSVC orders overloaded
   virtual methods unlike their declaration, so our declarations never overload virtual methods.
 - Memory crosses the boundary only through virtual methods (destructors, control blocks), so each side can use its
   own C runtime. Exceptions must not cross it.