Note: These results are totally wrong. Please see below.
Update: Note that the capture method I use needs to read pixels back from the GPU which can be slow. This means the Windows 10 results are probably worse than they should be. However, without external hardware this seems to be the only way to measure keyboard to screen latency.
Another update: After some discussions I’ve come to the conclusion that the Windows 10 latency values in the graph above aren’t really representative of the DWM latency. The pixel readback (and the GPU pipeline stall) takes a long time (20 ms after vsync!) so the sampling interval is very coarse. It also seems to be locked to display’s vertical refresh.
I didn’t consider this a big problem originally since I was after minimum latencies, so the interval between a keypress and the synced screen refresh roughly corresponds to the latency experienced by the user. But if that’s what we’re after there are better ways to measure it. It isn’t very interesting though since it’s just 8 ms on average.
I’m still sure there’s a frame or two of extra latency in there, but you should read this article just as an opionated rant :-)
I wiped off my Windows 10 installation today. It wasn't because of the intrusive telemetry or the ads in the start menu but desktop composition. It adds some slight but noticeable latency that makes typing feel uncomfortable. In Windows 7 you can turn it off.
In the figure below you can see that minimum latency you can reach in Windows 10 is about 8 milliseconds:
While in Windows 7 things are in general faster:
For example with GVim the average drops from 14 ms down to 5 ms when DWM (Desktop Window Manager) is disabled. At least I can feel the difference when typing. If you don't disable Aero in Windows 7 it's even worse than Windows 10.
Pavel Fatin has investigated key input processing latency at length in "Writing with pleasure". He summarizes the difference between stacking and compositing window manager as follows:
Stacking window managers orchestrate drawing of overlapped windows in such a way, that background windows are painted first. While this approach has some drawbacks (window content has to be restored explicitly), it introduces no additional delays because applications draw directly in the framebuffer. Examples of stacking window managers: Classic theme in Windows, Openbox in Linux.
Compositing window managers substitute the framebuffer with a dedicated off-screen buffer for each window, and then display all the windows together when (and how) they see fit. This separation inevitable leads to some latency increase. Examples of compositing managers: Aero in Windows, Compiz in Linux.
The thing with compositing window managers is that they seem to also enforce vertical synchronization (V-Sync). This means we need to wait until a picture is displayed on screen before we can start drawing the next one. This causes some latency. How much? Fatin writes:
Thus, we might expect additional delay before framebuffer update when vertical synchronization is turned on. Maximum delay is ~17 ms, average delay is ~8 ms (for 60 Hz refresh rate).
Eight milliseconds on average, not too bad. But actually the average seems to be two times that: roughly 17 ms and the minimum latency is 8 ms! I don't know if that 8 ms is the processing latency of the compositor or a bias in my frame capture method. Even with V-Sync enabled the minimum should be close to zero because sometimes we simply get lucky and happen to send the keypress just before the picture is sent to the display.
Anyway, the point is that there is a measurable difference in key input latency between Windows 10 and Windows 7 with no DWM. The difference is small but noticeable, and affects every user of Windows 10. In general, UI input latency is a known problem and a reason why e.g. your mouse cursor uses a special rendering path 1.
Some latency here or there, why is it a problem? Well, as a hobbyist nerd I know how to turn off desktop composition and how to install a different operating system if necessary. Most people just have to put up with it. In many cases you can't go and downgrade the OS of a work laptop even if you knew how. This isn't some obscure corner case but a regression in the core function of a modern PC.
Don't you find it a bit funny that Windows 95 is actually snappier than Windows 10? It's really a shame that response times in modern computers are visibly worse than those in twenty years ago.
The big problem with latency is that it accumulates. Once some component introduces delay somewhere in the input chain you aren't going to get it back. That's why it's really important to eliminate latency where you can. Also chances are that e.g. your keyboard is already slower than you might expect.
Apart from waiting for Microsoft to allow turning off the compositor in Windows 10 (not gonna happen) you can either
Actually, I don't know why a compositing window manager should enforce V-Sync anyway? Obviously you get screen tearing without it but the option should still be there for those who want it. You could throttle the update rate to e.g. 120 Hz in order not to burn too much power.
You can turn off desktop composition in the system Performance Options:
I used my own hacky measurement program written in C++ that sends a keypress to the application to be benchmarked. Then it waits until the character appears on screen. Virtual keypresses were sent with WinAPIs SendInput and pixels copied off screen with BitBlt. The plots were generated from data with 100 keypresses. I uploaded the data in its own repository too.
Program versions tested:
System specs:
Operating System: Windows 10 Pro 64-bit (10.0, Build 15063) (15063.rs2_release.170317-1834)
System Manufacturer: LENOVO
System Model: 20AMS0SQ08
BIOS: Phoenix BIOS SC-T v2.1
Processor: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz (4 CPUs), ~2.5GHz
Memory: 8192MB RAM
Available OS Memory: 7880MB RAM
Page File: 1807MB used, 7991MB available
DirectX Version: DirectX 12
User DPI Setting: Using System DPI
System DPI Setting: 96 DPI (100 percent)
DWM DPI Scaling: Disabled
Miracast: Available, with HDCP
Microsoft Graphics Hybrid: Not SupportedThere's also Pavel Fatin's Typometer tool but on Windows 10 it gave results quantized to 20 ms. That doesn't make sense since if you send the keypresses at arbitrary times, you should get varying latency depending on how close to the vertical blanking period you hit. Maybe I misunderstood something here? The Windows 10 results I recorded with this tool are also in the repository in typometer/ subdirectory.
The mouse cursor uses a special little bitmap in your GPU that gets overlaid separately on top of the framebuffer. The operating system can move the mouse by just telling the GPU to change the X and Y coordinates, so mouse position updates can skip the regular rendering queue. Even a single frame of latency in your mouse would be noticeable. For example in some games the cursor feels really heavy because they render it in software.↩
On Linux you can pick your own window manager. I've been using i3wm and it's fine.↩