Input lag

Input lag is the delay between pressing a button and seeing the game react. The potential causes for "input lag" are described below (steps which have negligible contributions to the input lag have been omitted). Each step in the process increases "input lag", however, the net result may be unnoticeable if the overall "input lag" is low enough.

Before diving in, let's distinguish between four key terms. Display lag, input lag, system latency, and netcode/network lag. They might sound similar, but they affect your experience in different ways. While display and system lag can subtly influence input lag, it's crucial not to mix them up.

See GamersNexus: Framerate Isn't Good Enough: Latency Pipeline, "Input Lag," Reflex, & Engineering Interview and Fixing GPU & CPU Benchmarks: Introducing Animation Error videos for more information about some of these.

Causes

Display

This is the lag caused by the modern displays/televisions/monitors (due to the nature of the digital technology). Digital image processing (such as upscaling, motion smoothing and edge smoothing etc.) takes time and therefore adds some degree of input lag. HD CRTs, LCDs, OLEDs and other digital displays do have digital image processing and cause noticable input lag.

Response time

Once the digital processing done, the pixels need time to switch to the new frame's colors, which is called 'pixel response time' (cause a blur on screen, so it's different from input lag), remember, pixel response affects how fast you see the image update, while input lag impacts how quickly the display reacts to your commands.

Analog CRT TVs and VGA CRT monitors and even HD CRTs have very fast response times but it's limited by phosphor decay time due to the nature of the technology. OLED displays have almost no blur on screen due to their very fast response time and also capable of displaying true black levels, which means that they do not require a backlight to produce an image and this allows OLEDs to turn individual pixels on and off much faster than LCDs, which require a backlight to produce an image.

While BFI (Black Frame Insertion) technology can significantly improve motion clarity for LCDs, it still falls short of both OLED and CRT in terms of both perceived clarity and motion resolution, though it's a great alternative/bridge the gap between these display technologies, offering a compromise between OLED's brightness and CRT's legendary motion, although at the cost of some flicker, potential extra input lag and reduced overall brightness. Although strobing (BFI) can eventually become obsolete in the future (including DyAc, ULMB, ELMB, VRB, etc) for modern content supporting 1000fps+ 1000Hz+ reprojection. This is a fully ergonomic PWM-free and flicker-free method of display motion blur reduction. No PWM or flicker.[1]

If you're in the market for a monitor or TV; check these websites for input lag and display lag performance of various display products. Some of the modern digital displays only have negligible amount of input lag and display lag and even some of them are near identical performance compared to Analog CRTs.

Input

actuation force demonstration, see this page

When it comes to delay of input devices most important thing usually is input controllers (ASICS/MCU/ECs), sensors and switches including switch designs. Wired/wireless usually doesn't matter (unless its Bluetooth with power saving mode); the thing that really matter is "consistency about polling rate"; polling rate fluctuations cause stutters and unstable input device feedback to users. When it comes to wireless technology "consistency" may be affected by lots of environmental factors.

See these websites for various controllers and keyboard/mouse devices for input lag performance benchmarks.

• Back in the days some people claim that DIN/mini-DIN connection keyboards and mice give better results compared to cheap USB connection peripherals due to the nature of the technology. Although this is far from the truth it has better handling of the data, whereas the USB busses can be more easily interrupted etc (kinda similar to wired/wireless polling consistency situation mentioned above).

Battle(non)sense: Keyboard Input Lag 125, 250, 500, 1000Hz USB vs. PS/2

• Make sure to use reasonable CPI/DPI and Polling rate values for USB devices because optimizing input and matrix resolution may affect input delay little bit.

Battle(non)sense: Low DPI vs. High DPI and Polling Rate Analysis

System (BIOS settings, bad drivers, OS misconfiguration) and placebo effect

Some people claims that default BIOS settings, Windows settings, registry settings, bloated services etc. causes little bit input delay and if you tweak these settings it will improve your system responsiveness. These kind of tweaks on internet considerably popular due to placebo effect but actually some of them really improves input delay a tiny bit. If you're obsessed with hacking your operating system and improving your system responsiveness even for a little bit you can check out FR33THY's latency analysis and also optimization pack which includes useful scripts. Most importantly make sure to use always proper and official drivers for your computer otherwise it may affect your system responsivess negatively (e.g. High DPC Latency, spikes, IRQ issues etc.)

See ways to reduce input lag section for reducing input delay.

Compositor

If you're using Windows Vista/7 and playing in windowed mode, having DWM enabled will add a noticeable amount of input lag because it forces vertical synchronization at the OS-level. The same thing applies to other OSes if their compositor uses V-Sync. Windows Aero and DWM can be disabled in both Vista and 7, thus disabling compositing and lowering input lag when playing in windowed mode, but this can no longer be done from Windows 8 onward due to WDDM 1.2+. That said, exclusive fullscreen should automatically disable compositing on all Windows OSes, making it the preferred way to emulate in most cases.

GPU driver

There is video latency caused by the GL drivers in Windows/Linux. Both the GLX X11 and Windows GL/D3D drivers are full of hacks, code paths, and buffer schemes that cater to benchmarking applications and games. This is counterproductive when the aim is low-latency audio and video synchronization for emulators. You don't want all this stuff going on in the background. This can be avoided by using KMS and DRM/EGL, specifically on Linux. By using these modes, the user is in control of front and back buffers and don't have to rely on APIs, so that they can find where and when a frame was dropped and how to act accordingly with that in mind. It is advisable to get the latest driver to improve performance, as notable graphics chip manufacturers (e.g. Nvidia) do not find KMS a priority. Intel and most AMD graphics chips, however, should be fine regardless, but it is still advisable to update drivers.

Ways to reduce input lag

Display

Option 1

• CRT TV OR VGA CRT (not HD CRTs) with analog input/output. If your GPU only support digital output then use high-end DAC/Digital-to-Analog converters for higher resolutions and refresh rates (Keep in mind that HDMI ones generally pretty bad). But what about digital-to-analog conversion input lag? See Aperture Grille's video about testing GPU-Passthrough and cheap DAC input lag results. Also see this thread for more information about high-end DACs.

Use Custom resolution/CRTSwitchRes solutions for displaying it on a CRT display in the correct resolutions. You could use built-in Custom resolution/CRTSwitchRes solutions like RetroArch's CRTSwitchRes or GroovyMAME using with CRT emudriver which is much more practical compared to using EDID editor tools such as Custom Resolution Utility (CRU) or using Linux in KMS mode. See #Enhancements sections in each page for "built-in custom resolution/CRTSwitchRes" support for emulators.

Option 2

• Fast-TN or IPS panel LCD or fast-OLED display, also make sure that you mitigate input lag on LCDs and OLEDs by turning on "game mode" from display OSD if available (this will turn off some post-processing options on display). If your LCD display is old set your native resolution to native panel resolution for preventing possible poor quality hardware display scaler otherwise you can use GPU scaling if you have at least mid range GPU.

If you have a "gaming" monitor you can also turn on "overdrive" option if available for overclocking pixels (applies overvoltage to pixels) making them react faster (better pixel response time) which results in less ghosting. That said, increasing pixel overdrive may cause inverse ghosting as the increased voltage can cause the pixels to overshoot the colors. See these websites and reviews to learn information about your display devices capabilities and performance.

Also you could use latest MAME with "-lowlatency" flag for your variable refresh rate supported monitor.

---

Input

1. Wired controller/input device (just for minimizing possible negative factors, just like using wired connection for router and client device)

---

System

1. Use exclusive fullscreen for Windows 8 and onwards if available because with borderless windowed and windowed fullscreen, due to WDDM 1.2 the desktop composition cannot be disabled anymore, so your only hope to avoid the compositing lag penalty is to play in exclusive fullscreen mode.

2. Turn off digital image processing and frame generation options from GPU driver control panel if it cause additional/noticeable input delay, some of the frame generation technologies can noticeably affect input delay, either positively or negatively, depending on the specific technique used[2]. Also if you're using intensive one turn off post-processing effects from applications/emulators and GPU driver control panel.

2.1. Turn on DLSS/FSR upscaling technologies if it increases your framerate which will likely decrease your latency.

3. Use input lag-mitigating techniques if application supports it.

3.1. A relatively new lag-mitigating technique known as Run-Ahead has recently been implemented in several emulators and frontends, which leverages spare performance overhead to run one or more instances of the emulator ahead of the regular instance, then uses save state rollback to lay that instance over what you see, effectively cutting a whole frame or more of input lag. Most games, even on real hardware on a CRT, have at least one hard-coded frame between executing an action on the controller and said action being reflected on screen, so setting Run-Ahead to 1 frame cuts out that superfluous frame and thus is usually considered safe, but setting it to 2 or more can result in dropped frames and perceived video stutter (though some games can benefit from 2 or more frames, particularly a lot of 5th-gen games). This is also quite processor-heavy, as every extra Run-Ahead frame requires a whole extra instance of the emulator, easily doubling or tripling CPU load, and some emulators are currently not able to use Run-Ahead at all. That said, combined with all the other lag reduction techniques on a sufficiently powerful system, Run-Ahead in theory can actually result in less input lag than even real hardware.

3.2. Another option for lag-mitigating technique known as Preemptive Frames. See this video for information.

4. Always make sure that your GPU is underutilized for preventing render queue bottleneck which causes considerable amount of input lag. If that is the case use framerate capping such as "in-game frame capping" or equivalent option from GPU driver control panel.

4.1. NVIDIA Reflex feature from in-game option will prevent this, but unfortunately not all GPUs and games supports this feature.

4.2. If you have a VRR capable display another option for you to prevent this is simply using both V-SYNC and "Low Latency Mode: ULTRA" or "AMD Anti-Lag+" options from GPU driver control panel; this will automatically prevent "render queue bottleneck".

4.2.1. Keep in mind that if you are using V-SYNC on non-VRR capable display, it will result "V-SYNC backpressure" which will cause additional input lag (especially if it includes triple buffering).

4.2.2. If you have a VRR capable display and using "AMD Anti-Lag+" and also want to eliminate tearing completely with all of these: you need to use framerate limiter again, because it does not keep the framerate inside the variable refresh rate range of the display unlike Nvidia's "Low Latency Mode: ULTRA" solution.

5. Some graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands. RetroArch's Synchronization Fences/Hard Sync for OpenGL does this. If you're using Vulkan backend, be sure to set the max swapchain images parameter to 2, though weaker GPUs (especially Intel iGPUs), can struggle with this, particularly if using intensive shader presets or increasing internal or rendering resolution.

6. Some emulator frontends like RetroArch or GroovyMAME have the option named "Frame Delay" to delay the processing of emulation for a few milliseconds until right before the given V-SYNC frame period is over, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the newer V-SYNC frame period. The amount of time you can use Frame Delay without dropping frames is dependent on the performance of the emulator on your machine. Use Automatic Frame Delay if you don't want to manually give a value for Frame Delay. Keep in mind that realistically, Frame Delay is the last thing to configure, after all other "sync and buffer settings" and "Input lag mitigation techniques" have been configured for your system's performance, as it gives the least lag reduction bang for your CPU load buck. Also "Predictive waiting" may also be forced with any DirectX based program through GeDoSaTo.

---

Summary

It cannot be understated how much system requirements increase the more lag reduction measures are employed. A computer or device that would normally be able to run an emulator or core at full speed with ease can suddenly find itself chugging with said measures implemented, especially once Run-Ahead and Frame Delay come into play, which may necessitate foregoing some of them. Some ways to alleviate the load and unlock more lag mitigation potential include making sure performance options are enabled, turning on speed hacks or dynarecs if applicable (to the extent that they don't hamper the game significantly, that is), or switching to faster, less accurate emulator/cores altogether, as the less CPU intensive an emulator is, the more performance overhead is left over for lag reduction. An example would be switching from bsnes to SNES9X, which trades cycle accuracy and compatibility with a handful of games for far greater performance and thus more room to reduce input lag. Also, as implied before, if you have to choose between Run-Ahead and Frame Delay, you should almost always choose Run-Ahead. Of course, if your system is powerful enough to run the most accurate emulators along with all the input lag reduction techniques all at once, go ahead and do so.

External Links

• inputlag.science - repository of knowledge about input lag in gaming
• Run-Ahead Wiki
• Mouse devices sensor list
• DestinyXZ9's investigations about input lag in various emulators
• RTINGS: Input Lag of Monitors
• RTINGS: Input Lag of TVs
• RTINGS: Pixel Response Time of Monitors
• RTINGS: Pixel Response Time of TVs
• TFTCentral: Reviews and Input Lag analysis of Monitors
• ApertureGrille: Reviews and Input Lag analysis of Monitors
• Controller latency on MiSTer
• Rocket Science: Controller Input Lag comparison video
• RTINGS: Mouse Click Latencies
• RTINGS: Mouse CPI and Speed-Related Accuracy Variation/SRAV results
• RTINGS: Mouse sensor latencies
• RTINGS: Keyboard Latencies
• mousespecs: Mouse Click Latencies
• Derek Wilson/AnandTech: Exploring Input Lag Inside and Out
• BlurBusters: Preview of NVIDIA G-SYNC, Part #2 Input Lag
• RetroRGB: BSNES Runahead Mode Lag Tested
• Rocket Jump Ninja - YouTube channel dedicated to mouse reviews
• Battle(non)sense - YouTube channel dedicated to analysing netcode performance of games and testing input lag, system responsiveness etc.
• FR33THY - YouTube channel dedicated to computer hardware and peripherals for testing input lag and system responsiveness etc.
• PPSSPP: Input lag too high, ideas for improvement
• Brunnis: An input lag investigation
• noodalls Input Lag Testing Results