3 ms·

> Virtual keypresses were sent with WinAPIs SendInput and pixels copied off screen with BitBlt. This methodology alone could account for the differences in tim

by jsd1982 9y ago

> Virtual keypresses were sent with WinAPIs SendInput and pixels copied off screen with BitBlt. This methodology alone could account for the differences in timing between Win7 and Win10. For all we know, Win10 could just be slower at getting the pixels back to the program from BitBlt, or SendInput could be slower triggering events, or a multitude of other issues. The best way to truly detect key-to-photon latency is with an external video recorder that has both the screen and keyboard in frame. Grant a few ms of noise for key travel distance.

leeter 9y ago
I'd be curious to see message traces and UMAPC (user mode asynchronous procedure calls) traces of this between the two. My hypothesis is that Win10 does quite a bit more in UMAPCs than win7 does in the interests of keeping the system 'responsive' even at the costs of latency. For those not aware UMAPCs only run when a thread is available in an 'alertable' state (see MSDN as that's not exactly simple to explain https://msdn.microsoft.com/en-us/library/windows/desktop/ms687069%28v=vs.85%29.aspx#alertablewaitfunctions https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ), as such they tend to wait for input or other runtime idle points unless the application makes very heavy use of windows built in asynchronous methods and alertable waits. I would also be curious to compare a D2D application versus a GDI application; as the majority of the work has gone to D2D in the last few years. Please note that D2D application in this case means one using a swap chain and device not an ID2DHWNDRenderTarget (this rasterizes and composites on the GPU but has GDI compatibility built in).
mastax 9y ago
As I understand it: - Compositing is done on the GPU - BitBlt is done on the CPU - Copies from GPU -> CPU are slow So, yeah, compositing adds a frame of VSync latency, but these measurements are complete bunkum.
- leeter 9y ago
  BitBlt is done in DMA ram by the CPU, so it may be even worse than just a copy as there is likely a wait involved too to prevent shared access. Using DMA ram prohibits the GPU/Driver from doing optimizations on that ram that it could do if the buffer was in dedicated gpu-ram. This is why DX12 resources are generally always copied into non-shared buffers.

leeter 9y ago

I'd be curious to see message traces and UMAPC (user mode asynchronous procedure calls) traces of this between the two. My hypothesis is that Win10 does quite a bit more in UMAPCs than win7 does in the interests of keeping the system 'responsive' even at the costs of latency. For those not aware UMAPCs only run when a thread is available in an 'alertable' state (see MSDN as that's not exactly simple to explain https://msdn.microsoft.com/en-us/library/windows/desktop/ms687069%28v=vs.85%29.aspx#alertablewaitfunctions https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ), as such they tend to wait for input or other runtime idle points unless the application makes very heavy use of windows built in asynchronous methods and alertable waits. I would also be curious to compare a D2D application versus a GDI application; as the majority of the work has gone to D2D in the last few years. Please note that D2D application in this case means one using a swap chain and device not an ID2DHWNDRenderTarget (this rasterizes and composites on the GPU but has GDI compatibility built in).

mastax 9y ago

As I understand it: - Compositing is done on the GPU - BitBlt is done on the CPU - Copies from GPU -> CPU are slow So, yeah, compositing adds a frame of VSync latency, but these measurements are complete bunkum.

leeter 9y ago
BitBlt is done in DMA ram by the CPU, so it may be even worse than just a copy as there is likely a wait involved too to prevent shared access. Using DMA ram prohibits the GPU/Driver from doing optimizations on that ram that it could do if the buffer was in dedicated gpu-ram. This is why DX12 resources are generally always copied into non-shared buffers.