A renderer separates work into a build phase and a draw phase. During the build phase, the application creates and modifies renderer objects, updates buffers, changes resource bindings, and edits the render tree for a future frame. During the draw phase, the renderer consumes a latched snapshot of the render tree and submits the corresponding graphics work.

The application advances build state to the draw phase by calling StartNewFrame. When this method is called, the current build state is latched for drawing and the application can begin preparing later changes. The renderer protects the frame being drawn from later application edits. Buffers can be modified, nodes can be added or removed, and resources can be released without changing the already submitted frame.

StartNewFrame is the important boundary between application-side edits and renderer-side draw work. It may return before the GPU work for the frame is complete, which lets the application continue preparing future frames. It may also need to wait for renderer synchronization when previous work has not reached a safe point for another frame submission.

The method must be externally synchronized with all other calls on the renderer and any objects created by it. This requirement is described in more detail in the Threading Model page.

Renderer objects are released through smart pointers, but the native graphics resources behind them may be kept alive until the renderer knows they are no longer used by an in-flight frame. This deferred deletion model makes it safe to release objects while previous frames are still drawing.

When an application needs a strict cleanup point, for example before destroying a native window that was bound to a framebuffer, call WaitForDeferredDeletionComplete after releasing the relevant renderer objects. This advances the renderer to a point where deferred destruction has completed.

Output capture and readback operations also follow the draw/build split. Requesting a framebuffer, data array, or texel array output capture schedules work that completes asynchronously with the frame. Use WaitForOutputCaptureComplete before consuming captured output that must be available immediately.

Waiting for output capture is heavier than letting frame work proceed naturally, so it is best reserved for tests, screenshots, diagnostics, or application features that genuinely need a CPU-side copy at that point.