Changes

===Display lag===This is the lag caused by the modern displays/televisions/monitors (due to the nature of the digital technology). [[Wikipedia:Digital_image_processing|<abbr title="Shouldn't be confused with analog image processing.">Digital image processing</abbr>]] (such as upscaling, motion smoothing and edge smoothing etc.) takes time and therefore [https://www.rtings.com/monitor/tests/inputs/input-lag#why-there-s-input-lag adds some degree of input lag]. [[Displays#CRT_TVs|HD CRTs]], LCDs, OLEDs and other digital displays do have digital image processing and cause noticable input lag.

This is the lag caused by :;Response time:Once the digital televisions and monitors. Image processing (such as upscalingdone, 100&nbsp;Hzthe pixels need time to switch to the new frame's colors, 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 which is not noticeable.<ref>httpcalled '[https://www.bit-techrtings.netcom/hardwaremonitor/monitorstests/2009motion/02/06/themotion-darkblur-sideand-ofresponse-overdrive/4</ref> Discussions time pixel response time]' (cause a blur on gaming forums tend to agree with this value. Once the frame has been processedscreen, so it's different from input lag), remember, the final step is the pixel response time for affects how fast you see the image update, while input lag impacts how quickly the pixel display reacts to display the correct color for the new frameyour commands.

:Analog [[Display FAQ#CRT TVs|CRT TVs]] and [[Display_FAQ#CRT_monitors|VGA CRT monitors usually ]] and even [[Displays#CRT_TVs|HD CRTs]] have no display lag, the exception being later model CRT TVs that do HD, 100Hz or 480p inputs, which use scaling.===Windows Aero===If youvery fast response times but it're using Windows Vista/7, having s limited by [https://enold.wikipediareddit.orgcom/r/crtgaming/comments/wikiqyx4r3/Windows_Aero Aerois_this_normal_for_a_crt_monitor_if_not_is_there/ phosphor decay time] enabled will add a noticeable amount due to the nature of input lag because it forces vertical synchronization at the OS-leveltechnology. The same thing applies [[Displays#OLED_Monitors|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 other OSs if compositing is enabled with VSync. Exclusive fullscreen should automatically disable compositingproduce an image and this allows OLEDs to turn individual pixels on and off much faster than [[Displays#LCD_monitors|LCDs]], which require a backlight to produce an image.

:While <abbr title===GPU driver latency==="Flicker/PWM/BFI/strobe-based motion blur reduction such as LightBoost, ELMB, ULMB, VRB, DyAc, PureXP etc.">BFI (Black Frame Insertion)</abbr> 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.[https://blurbusters.com/frame-generation-essentials-interpolation-extrapolation-and-reprojection#dev]

There is video latency caused by the GL drivers If you're in Windows/Linux. Both the GLX X11 market for a monitor or TV; check [[Input_lag#External_Links|these websites]] for input lag and Windows GL/D3D drivers are full display lag performance of hacks, code paths, and buffer schemes that cater to benchmarking applications and gamesvarious display products. This is counterproductive when Some of the aim is low-latency audio modern digital displays only have negligible amount of input lag and video synchronization for emulators. You don't want all this stuff going on in the backgrounddisplay lag and even some of them are near identical performance compared to Analog CRTs.

Hard GPU sync options in some emulator frontends can reduce or remove latency from buffering at ===Input===[[File:Keyboard Switches demonstration.gif|thumb|298px|[https://thegamingsetup.com/gaming-keyboard/buying-guides/keyboard-switch-chart-table actuation force] demonstration, see [https://www.x360ce.com/Keyboards this page]]]When it comes to delay of input devices most important thing usually is [[Wikipedia:Keyboard_controller_(computing)|input controllers]] (ASICS/MCU/[[Wikipedia:Embedded_controller|ECs]]), [[#External_Links|sensors]] and [[Wikipedia:Miniature_snap-action_switch|switches]] including [https://deskthority.net/wiki/Category:Keyboard_switches_by_design switch designs]. Wired/wireless usually doesn't matter ([https://kanuan.github.io/DS4WSite/troubleshooting/input-delay-bt/ unless its Bluetooth with power saving mode]); the possible expense thing that really matter is "[https://forums.blurbusters.com/viewtopic.php?t=6162&start=10#p55425 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 performanceenvironmental factors.

This can be avoided by using See [https://en.wikipedia.org/wiki/Mode_setting KMS] and [https://en.wikipedia.org/wiki/Direct_Rendering_Manager DRMInput_lag#External_Links|these websites]/[https://en.wikipedia.org/wiki/EGL_(API) EGL], specifically on Linux. By using these modes, the user is in control of front for various controllers 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 keyboard/mouse devices for input lag 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 driversbenchmarks.

Low* Back in the days some people claim that [[Wikipedia:DIN_connector|DIN/mini-level APIs such as Vulkan DIN connection]] keyboards and mice give better results compared to cheap [[Wikipedia:USB|USB connection]] peripherals due to the user control over buffering and may lower latency without resource-heavy solutions like hard GPU syncnature of the technology. However, there Although this is evidence that OpenGL has lower latency than Vulkan in some instances.<ref>far from the truth [https://forums.libretroblurbusters.com/viewtopic.php?t=8411#p65756 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).:: [https:/an-input-lag-investigation/4407www.youtube.com/291<watch?v=eEswl6kZq5k Battle(non)sense: Keyboard Input Lag 125, 250, 500, 1000Hz USB vs. PS/ref>2]

* Make sure to use reasonable CPI/DPI and Polling rate values for USB devices because optimizing [https://www.youtube.com/watch?v=lc7JVjcPzL0 input and matrix resolution] may affect input delay little bit.:: [https://www.youtube.com/watch?v==Controller===6AoRfv9W110 Battle(non)sense: Low DPI vs. High DPI and Polling Rate Analysis]

For wired controllers===System (BIOS settings, this lag is negligiblebad 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. For wireless controllers, opinions vary as These kind of tweaks on internet considerably popular due to the placebo effect but actually some of this lagthem really improves input delay a tiny bit. Some noticed extra lag when using If you're obsessed with hacking your operating system and improving your system responsiveness even for a wireless controller, while others didn't.<ref>httplittle bit you can check out [https://wwwdocs.lockergnomegoogle.com/uncategorizedspreadsheets/2011d/0819rFOoJtx8OTF7GumSxwhB_3oCQ5bmY4bSpth7ef69Iw/26/wireless-controller-edit#gid=0 FR33THY's latency-is-it-a-problemanalysis] and also [https:/</ref>www.youtube.com/watch?v=89R9KlJ3ocM 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.)

Testing has found that overall "====[[Wikipedia:Compositing_window_manager|Compositor]]====If you're using Windows Vista/7 and playing in windowed mode, having [[Wikipedia:Desktop_Window_Manager|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. [[Wikipedia:Windows_Aero|Windows Aero]] and [[Wikipedia:Desktop_Window_Manager|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 controller input Windows 8 onward due to [[Wikipedia:Windows_Display_Driver_Model#WDDM_1.2|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 display responsebenchmarking 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 [[Wikipedia:Mode_setting|KMS]] and [[Wikipedia:Direct_Rendering_Manager|DRM]]/[[Wikipedia:EGL_(API) times |EGL]], specifically on Linux. By using these modes, the user is in control of approximately 200ms are distracting 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 userlatest driver to improve performance, as notable graphics chip manufacturers (e.g. Nvidia) do not find KMS a priority.<ref>http[https://wwwdeveloper.eurogamernvidia.netcom/articlesblog/digitalfoundryunderstanding-and-lagmeasuring-factorpc-article?page=2latency/ nvidia: Understanding and Measuring PC Latency]</ref> It also appears that (excluding the monitor/television display lag) 133ms is an average response time Intel and the most sensitive games achieve response times of 67ms (againAMD graphics chips, however, should be fine regardless, excluding display lag)but it is still advisable to update drivers.

Use:----;Input*'''1.''' Wired controller/input device (just for minimizing possible negative factors, just like using wired connection for router and client device)*Linux OS in KMS mode<ref>https://wiki.archlinux.org/index.php/kernel_mode_setting</ref><ref>https://github.com/libretro/RetroArch/wiki/KMS-mode</ref>---;System*Exclusive '''1.''' Use exclusive fullscreen (Not for Windows 8 and onwards if available because with borderless windowedand windowed fullscreen, or windowed due to [[Wikipedia:Windows_Display_Driver_Model#WDDM_1.2|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)*CRT TV or monitormode.

If you don't have a CRT or can''2.''' Turn off digital image processing and [https://youtu.be/NzYvudM9BmI?t be bothered with one=723 frame generation] options from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel] if it cause additional/noticeable input delay, you some of the frame generation technologies can mitigate noticeably affect input lag delay, either positively or negatively, depending on LCDs by setting the display to game mode if available specific technique used[https://blurbusters.com/frame-generation-essentials-interpolation-extrapolation-and also only pass them their native resolution-reprojection]. This turns Also if you're using intensive one turn off some post-processing effects from applications/emulators and reduces scaling delay, [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel].:'''2.1.''' Turn on DLSS/FSR upscaling technologies [https://youtu.be/-ajK3netvv4?t=173 if it increases your framerate which both introduce lagwill likely decrease your latency].

To disable Windows Aero under Windows Vista'''3.''' Use [https://emulation.gametechwiki.com/index.php?search=%22%23Enhancements|Enhancements%22&title=Special%3ASearch&limit=500&profile=default&fulltext=1 input lag-mitigating techniques] if application supports it.:'''3.1.''' A relatively new lag-mitigating technique known as [https://github.com/higan-emu/emulation-articles/tree/7master/input/run-ahead Run-Ahead] has recently been implemented in several emulators and frontends, select which leverages spare performance overhead to run one or more instances of the Basic or Classic theme under Control Center > Personalizationemulator ahead of the regular instance, then uses save state rollback to lay that instance over what you see, effectively cutting a whole frame or disable desktop composition under more of input lag.exe properties > Compatibility. Some emulators Most games, even on real hardware on a CRT, have at least one hard-coded frame between executing an action on the controller and frontends allow you said action being reflected on screen, so setting Run-Ahead to disable desktop composition without having 1 frame cuts out that superfluous frame and thus is usually considered safe, but setting it to switch themes2 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). The desktop composition will This is also be disabled by playing under quite processor-heavy, as every extra Run-Ahead frame requires a whole extra instance of the non-windowed fullemulator, easily doubling or tripling CPU load, and some emulators are currently not able to use Run-screen modeAhead at all. In Windows 8 and laterThat said, combined with all the desktop composition cannot be disabled manuallyother 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 [https://www.youtube.com/watch?v=NDYqRoyOKI4 this video] for information.

Triple buffering '''4.''' Always make sure that your [https://youtu.be/7DPqtPFX4xo?t=72 GPU is underutilized] for preventing [https://youtu.be/K_k1mjDeVEo?t=83 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 [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel].:'''4.1.''' [https://youtu.be/7DPqtPFX4xo?t=650 NVIDIA Reflex feature] from in-game option will inherently add prevent this, but unfortunately not all GPUs and [https://www.nvidia.com/en-gb/geforce/technologies/reflex/supported-products/ games supports this feature].:'''4.2.''' If you have a few frames of VRR capable display another option for you to prevent this is simply using both [[Vsync|V-SYNC]] and "Low Latency Mode: ULTRA" or "AMD Anti-Lag+" options '''from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]'''; this will automatically prevent "render queue bottleneck".<ref name=renderqueueandvsyncbackpressure>[https://www.nvidia.com/en-us/geforce/guides/gfecnt/202010/system-latency-optimization-guide/ Nvidia: System latency optimization guide], [https://forums.blurbusters.com/viewtopic.php?t=8645 BlurBusters thread: Nvidia Reflex and low latencymode]</ref>::'''4. So disable 2.1.''' Keep in mind that wherever possibleif you are using [[Vsync|V-SYNC]] on non-VRR capable display, either through emulator settings or driver settingsit will result "V-SYNC backpressure" which will cause additional input lag [https://youtu.be/L07t_mY2LEU?t=530 (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: [https://youtu.be/K_k1mjDeVEo?t=727 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<ref>. RetroArch's [[Vsync#Hard_GPU_Sync|Synchronization Fences/Hard Sync]] for OpenGL does this. If you're using Vulkan backend, be sure to set the [https://wwwarm-software.twentymillisecondsgithub.comio/vulkan_best_practice_for_mobile_developers/postsamples/latency-mitigation-strategiesperformance/#toc_7<swapchain_images/ref>swapchain_images_tutorial. html max swapchain images] parameter to 2, though weaker GPUs (especially Intel iGPUs), can struggle with this, particularly if using intensive [[Shader_Presets|shader presets]] or increasing [[RetroArchResolution|internal or rendering resolution]]'s Hard Sync does this.

[[File:Vsync and Predictive Waiting'''6.png]] ''' Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option named "[https://www.libretro.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Frame Delay]" to delay the processing of emulation for a few milliseconds until right before a vsync occursthe given V-SYNC frame period is over, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) vsync newer V-SYNC frame period. The amount of time you can use frame delay Frame Delay without dropping frames is dependent on the performance of the emulator on your machine. Predictive waiting may also be forced with any DirectX based program through GeDoSaTo<ref>httpUse [https://blogwww.metaclassofnillibretro.com/?p=715<index.php/ref>retroarch-1-9-13-automatic-frame-delay/ Automatic Frame Delay] if you don't want to manually give a value for Frame Delay. RealisticallyKeep in mind that realistically, this 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'' [https://community.pcgamingwiki.com/files/file/897-gedosato/ GeDoSaTo].----;SummaryIt 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 [[Emulation_accuracy|accurate]] emulator/cores altogether, as the less CPU intensive an emulator is, the more performance overhead is only useful left over for lag reduction. An example would be switching from bsnes to SNES9X, which trades [[Emulation_accuracy|cycle accuracy]] and compatibility with significantly a handful of games for far greater performance and thus more power than 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 required powerful enough to run the most [[Emulation_accuracy|accurate]] emulators along with all the input lag reduction techniques all at full speedonce, go ahead and do so.