Input lag
Input lag is the delay between pressing a button and seeing the game react.[1] 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.
Contents
Causes
Display lag
This is the lag caused by the digital televisions and monitors. Image processing (such as upscaling, 100 Hz, motion smoothing, edge smoothing) takes time and therefore adds some degree of input lag. It is generally considered that input lag of a television below 30ms is not noticeable.[2] Discussions on gaming forums tend to agree with this value. Once the frame has been processed, the final step is the pixel response time for the pixel to display the correct colour for the new frame.
CRT TVs and monitors have no display lag.
Windows Aero
If you're using Windows Vista/7, having Aero enabled will add a noticeable amount of input lag because it forces vertical synchronization at the OS-level.
GPU driver latency
There is video latency caused by the GL drivers in Windows/Linux. It is a total black box and they do all sorts of crazy buffering schemes under the hood for all sorts of purposes - better scores with benchmarking tests, better "game" results - but it is actually counter productive when your aim is low-latency audio/video synchronization for emulators - you don't want all this stuff going on in the background. This applies to both GLX X11 drivers and Windows GL/D3D drivers - both are full of bad hacks and codepaths that cater to benchmarking applications and games.
Hard GPU sync options in some emulator frontends can reduce or remove latency from buffering at the possible expense of performance.
This can be avoided by using KMS and DRM/EGL, specifically on Linux; using these, 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. AMD, Nvidia) do not find KMS a priority. Intel graphics chips, however, should be fine regardless, but it is still advisable to update drivers.
Low-level APIs such as Vulkan also award the user control over buffering, and as such potentially afford low latency without the need for workarounds like hard GPU sync.
Controller
For wired controllers, this lag is negligible. For wireless controllers, opinions vary as to the effect of this lag. Some people claim to notice extra lag when using a wireless controller, while other people claim that the 4-8 milliseconds of lag is negligible.[3]
Typical overall response times
Testing has found that overall "input lag" (from controller input to display response) times of approximately 200ms are distracting to the user.[4] It also appears that (excluding the monitor/television display lag) 133ms is an average response time and the most sensitive games achieve response times of 67ms (again, excluding display lag).
Ways to reduce input lag
Use:
- Wired controller
- CRT TV or Monitor
- Linux OS in KMS mode
To disable Windows Aero under Windows Vista/7, select the Basic or Classic theme under Control Center > Personalization, or disable desktop composition under .exe properties > Compatibility. Desktop composition will also be disabled by playing under non-windowed fullscreen. In Windows 8, desktop composition cannot be disabled manually.
Some emulator frontends such as RetroArch or GroovyMAME have the option to delay processing of emulation for a few milleseconds until right before a vsync occurs, which causes inputs to be polled immediately before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) vsync period. The amount of time you can use frame delay without dropping frames is dependent on the performance of the emulator on your machine.
