Skip to content

Conversation

@RT2Code
Copy link
Contributor

@RT2Code RT2Code commented Oct 25, 2025

Frames in flight can improve and stabilize the framerate, but they may also introduce some input lag, because frames are buffered ahead of time. Allowing the user to set just one frame in flight, effectively disabling frame queuing, can be useful in scenarios where minimizing input latency is more important than maximizing throughput.

Currently, if the user specify only one frame in flight, the DX12 backend crashes. Just to be clear, this is not a regression introduced by #8961, it was already present beforehand.

The crash occurs because, unlike the example implementation, the backend links the back buffer count directly to the number of frames in flight. If you set 1 frame in flight, the backend will use 1 backbuffer, but DXGI_SWAP_EFFECT_FLIP_DISCARD requires at least 2 back buffers, causing the swapchain creation to fail.

To fix this, it was necessary to decouple the back buffer count from the frame in flight count. The back buffer related members have been moved from ImGui_ImplDX12_FrameContext to a new structure, ImGui_ImplDX12_Backbuffer, allowing each to have a different count. I also added a BackBuffer field to ImGui_ImplDX12_InitInfo so users can configure it explicitly.

…itInfo::BackBuffer and add support for a single frame in flight
@kjm99d
Copy link

kjm99d commented Oct 30, 2025

With this change the waitable object latency is tied to numBackbuffer.
If a user sets NumFramesInFlight = 1 but keeps two back buffers (needed for flip discard), latency goes back to 2 and input lag returns.
Can we keep SetMaximumFrameLatency(bd->numFramesInFlight) so the user can effectively opt into one frame in flight?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants