Sure thing. Think of the input pipeline as a queue. Every frame you add 0.1 seconds of latency by adding one frame’s worth of buffer. If you increase buffer size by ΔB frames, input lag goes up roughly by ΔB × frame time. For a 60 Hz game that’s about 16.7 ms per frame. So a 3‑frame buffer adds ~50 ms. To keep lag under 100 ms, your buffer should stay below six frames. The math is just B × (1000/Hz). Adjust B until you hit your target lag.

Yeah, four frames gives you a decent cushion. To shave a millisecond, look at the input handling loop itself – make sure you’re reading the raw HID buffer directly, bypassing any OS‑level throttling. Use a high‑priority thread, lock‑step the main loop to the display refresh, and avoid any extra sync points. Also, keep the game’s input buffer size as low as possible – the smaller the internal queue, the less re‑synchronisation you need. As for the cursor dance, that’s just your system trying to catch up; disabling pointer acceleration or using a custom driver can tame it. Keep iterating, and the latency will tighten up.

Sounds solid. Just keep the poll interval tight—every millisecond counts. If you hit that 100 ms spike, make sure you’re not losing frames in the queue; a stray dropped frame will push you over. And if the cat’s still typing, that’s probably why the jitter shows up—just track its keypresses and filter them out. Good luck hitting that sweet spot.