Reduce input latency with double buffering

[tfriedel]

Summary

• Reduce swap chain buffer count from 3 to 2
• Disable vsync (sync interval 0) in Present calls to reduce latency

Motivation

Triple buffering with vsync causes ~33ms (2 frames at 60Hz) of input latency. By switching to double buffering and disabling vsync, measured input latency drops to ~15.5ms (SD 4.2ms) as measured with typometer.

Test plan

• Build and deploy Windows Terminal
• Measure input latency with typometer
• Verify no visual artifacts or tearing on various monitors/refresh rates
• Test stability during window resize and screen capture

🤖 Generated with Claude Code

[DHowett]

For what it is worth, 3 buffers were chosen for a reason which is documented exactly above the lines of code you have changed. Do you have a solution that will solve the new purported issue and the original issue that drove us to use triple buffering?

[tfriedel]

For what it is worth, 3 buffers were chosen for a reason which is documented exactly above the lines of code you have changed. Do you have a solution that will solve the new purported issue and the original issue that drove us to use triple buffering?

thanks for this insight!
I'll have to see how I can reproduce this problem first.
And then I'd try to check other terminals that have lower input latency like alacritty if they also have this issue.

[tfriedel]

I think we can close this PR. I found that the current main branch has lower latency already anyway. Seems like between preview version and canary build ( 1.25.10161.0 ) you improved it?

[lhecker]

I think we can close this PR. I found that the current main branch has lower latency already anyway. Seems like between preview version and canary build ( 1.25.10161.0 ) you improved it?

#19330 if anything. Aside from that there haven't been any rendering changes in 1.5 years. I re-reviewed that PR and it is functionally identical to before. Perhaps we made improvements in the VT processing, but I don't think there are any changes in the rendering code.

Triple buffering with vsync causes ~33ms (2 frames at 60Hz) of input latency.

That's not how buffering works. The number of buffers you specify in 3D rendering controls only that: How many buffers you got. Whether that affects your latency depends on your coding. So, there are signals from the GPU to detect when it presents a buffer on the screen. If you use that signal, you could have 1000-ary buffering and you would still have the same latency as if you only used double-buffering.

As someone who uses LLMs quite a bit, I hope LLM providers can fix their AIs zealously jumping to conclusions in the near term. Because I tried asking Claude about this as well and it made the exact same mistake it did in your PR. Asking it about DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT then makes it realize its mistake. But why?! The DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT is just 14 lines above!

[tfriedel]

@lhecker
yes, the PR you mentioned was it. I did run typometer with a version one commit before that and then with the changes in the PR and noticed input latency dropped from 33 ms to 17-18. I should have of course tried this before even working on this.

I spent some time using claude code and codex on improving latency and rendering smoothness in wezterm and also here, but I have to agree, they were not really up to the task.

And thanks for the explanation with the buffering, it was not clear to me.