4 ms·

I will gladly believe this is a real problem, but this page does not demonstrate that (at least not convincingly); the metric used is simply too poor. To quote

by emn13 9y ago

I will gladly believe this is a real problem, but this page does not demonstrate that (at least not convincingly); the metric used is simply too poor. To quote: > 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. So, this is measuring some rather artificial and fairly uninteresting time. You really do need to measure the complete stack here, especially if your theory is that issues like vsync are at stake, because the level at which vsync happens can vary, and because there are interactions here that may matter. E.g. if there are 100 reasons to wait for vsync, and you remove one of them... you're still going to wait for vsync. It's not 100% clear that this measurement actually corresponds to anything real. Also, note that a compositor need not necessarily do anything on the CPU, so by trying read back the composited image, you may inadvertently be triggering some kind of unnecessary (or OS-dependent sync). E.g. it's conceivable that regardless of tearing on screen you want the read-back to work "transactionally", so you might imagine that a read requires additional synchronization that mere rendering might not. And of course: all this is really complicated, there are many moving part's we're bound to overlook. It's just common sense to try to measure something that matters, to avoid whole classes of systemic error. Ideally, you'd measure from real keypress upto visible light; but at the very least you'd want to measure from some software signal such as SendInput up to an hdmi output (...and using the same hardware and as similar as possible software). Because at the very least that captures the whole output stack, which he's interested in. Another advantage of a whole-stack measurement is that it puts things into perspective: say the additional latency is 8ms; then it's probably relevant to know at least roughly how large the latency overall is.

astrodust 9y ago
Once you throw in another 15+ms of keyboard and USB latency...
chillee 9y ago
Just another point of data with compton compositor on Arch with several text editors. https://news.ycombinator.com/item?id=14800713 https://news.ycombinator.com/item?id=14800713
modeless 9y ago
The time measured is artificial but not necessarily uninteresting. You can't measure the true end to end latency this way, but you can compare different user applications to see how much latency they add. It's not perfect but it is the best available way to measure latency of arbitrary applications without extra hardware. I built a browser latency benchmark based on a similar method: https://google.github.io/latency-benchmark/ https://google.github.io/latency-benchmark/ I did plenty of testing and found that the measurements obtained this way do correlate with true hardware based latency measurement. All that said, it is a travesty that modern OSes and hardware platforms do not provide the appropriate APIs to measure latency accurately. A lot of what is known about latency at low levels of the stack is thrown out before you get to the APIs available to applications.
- emn13 9y ago
  I'm sure they correlate: but the thing with correlation is that you can have correlation even when there are whole classes of situations where the relationship doesn't hold. On the same os +drivers I'd be willing to believe that this measure is almost certainly useful (even there, it's not 100%). But it's exactly the kind of thing that a different way of, say... compositing... might the implementation to work a little differently, such that you're comparing apples to oranges. If BitBlt simply gets access a little earlier or later in the same pipeline and hey presto: you've got a difference in software that is meaningless in reality.
stinos 9y ago
Ideally, you'd measure from real keypress upto visible light; This, I think. When measuring latencies for e.g. reaction time experiments for neurophysiology I'd always use a photodiode or similar to figure out when things actually get on the screen as that's the only thing which matters. IIRC this was always with V-Sync on, but still with custom DirectX applications it was impossible to get lower than 2 frames of latency on Windows 7. So it has always been a bit mistery to me how these articles talk about latency of keyboard to screen of < 1 actual frame. Maybe this explains it, i.e. they're not measuring actual latency from keyboard to screen? I just don't know enough about graphics but even with V-Sync off I'm not sure you can just tell the GPU 'hey here's a pixel now put it on screen right now'?

by emn13 9y ago

astrodust 9y ago

Once you throw in another 15+ms of keyboard and USB latency...

chillee 9y ago

Just another point of data with compton compositor on Arch with several text editors. https://news.ycombinator.com/item?id=14800713 https://news.ycombinator.com/item?id=14800713

modeless 9y ago

The time measured is artificial but not necessarily uninteresting. You can't measure the true end to end latency this way, but you can compare different user applications to see how much latency they add. It's not perfect but it is the best available way to measure latency of arbitrary applications without extra hardware. I built a browser latency benchmark based on a similar method: https://google.github.io/latency-benchmark/ https://google.github.io/latency-benchmark/ I did plenty of testing and found that the measurements obtained this way do correlate with true hardware based latency measurement. All that said, it is a travesty that modern OSes and hardware platforms do not provide the appropriate APIs to measure latency accurately. A lot of what is known about latency at low levels of the stack is thrown out before you get to the APIs available to applications.

emn13 9y ago
I'm sure they correlate: but the thing with correlation is that you can have correlation even when there are whole classes of situations where the relationship doesn't hold. On the same os +drivers I'd be willing to believe that this measure is almost certainly useful (even there, it's not 100%). But it's exactly the kind of thing that a different way of, say... compositing... might the implementation to work a little differently, such that you're comparing apples to oranges. If BitBlt simply gets access a little earlier or later in the same pipeline and hey presto: you've got a difference in software that is meaningless in reality.

stinos 9y ago

Ideally, you'd measure from real keypress upto visible light; This, I think. When measuring latencies for e.g. reaction time experiments for neurophysiology I'd always use a photodiode or similar to figure out when things actually get on the screen as that's the only thing which matters. IIRC this was always with V-Sync on, but still with custom DirectX applications it was impossible to get lower than 2 frames of latency on Windows 7. So it has always been a bit mistery to me how these articles talk about latency of keyboard to screen of < 1 actual frame. Maybe this explains it, i.e. they're not measuring actual latency from keyboard to screen? I just don't know enough about graphics but even with V-Sync off I'm not sure you can just tell the GPU 'hey here's a pixel now put it on screen right now'?