A frame can finish quickly even though the player's latest action spent time waiting behind it. During the Vulkan rendering work, I needed to account for both. Waiting for the display, or waiting to enforce a frame-rate cap, should not also hold up input processing and incoming server results.
I gave that work its own service. It reads input, predicts the player's movement and consumes the server's results independently of drawing. The renderer receives completed snapshots of that work, which it can read but cannot change.
A shot also needs a stable reference to the world it was aimed at. The timing rules select that scene reference and then lock it; a newer rendered frame cannot quietly replace it afterward. For a rail shot, the server checks both the historical scene and the position the player was allowed to fire from. Keeping the aim attached to the right scene matters even when displaying the next frame has to wait.
Removing an unnecessary rendering step
The October 21 optimization addressed a separate cost. At native resolution, with the FXAA edge-smoothing filter disabled, I could draw the scene directly. There was no need to first draw it into an intermediate image and then combine that image into the full screen when neither scaling nor that filter was required. Scaled scenes, previews and FXAA still use their intermediate rendering targets.
I compared the two paths with the same eight-player Windwalk test scene at 3440 × 1440. The mean time to complete a frame fell from 1.554 ms to 1.419 ms, a reduction of about 8.7%. Crowded scenes at 1080p showed much smaller changes. Keeping those results together shows where the optimization helped and where it made little difference.
This benchmark draws a fixed scene and waits for the graphics processor to finish. It does not run live input, the heads-up display, audio or networking. Dividing a second by its frame time would produce a number, but that number would not be a measured live-game frame rate. It would not tell us how long a physical mouse movement takes to reach the display either.
Checking the response path separately
I checked native builds with rendering capped and uncapped, both implementations of the QUIC network transport, delayed service work, and renderer startup and shutdown behavior. Broader tests of hardware input events, display timing and Internet conditions remained separate work.
The rendering comparison tells me that one scene became cheaper to draw. The input work addresses a different requirement: processing an action against the correct state of the fight while presentation continues at its own pace. The netcode page follows that path and the evidence behind it.