3 ms·
Correct me if I'm wrong, but this doesn't seem to measure input stack latency nor how long it takes for the pixels to be actually visible on the display after a
by vardump 6y ago
Correct me if I'm wrong, but this doesn't seem to measure input stack latency nor how long it takes for the pixels to be actually visible on the display after all of the compositing delays.
All this measures seems to be time from injected keyboard event until pixels change on whatever bitmap/surface in memory. Message passing, in other words.
- wtallis 6y agoThat sounds like it's measuring almost exactly the portion of the end-to-end latency that an application can actually do anything to reduce; the rest is in hardware and drivers. So it would definitely be a useful measure, but cutting this measured latency in half won't cut the entire end-to-end latency in half.
- vardump 6y agoApplication might be able to make choices about APIs that affect output latency. Hardware swap chain (AKA multi-plane overlay) is going to be visible on the screen at least one full vsync faster than something that's composited on a frame buffer. In the best case, this measuring method wouldn't see any difference in such case. In the worst case reading pixels from the screen might even misleadingly measure worse due to triggering a corner case code path in the window compositor. Using an emulated legacy API (like Windows GDI) might yield a very low latency score in this test, even though it might take much longer to actually be visible on the display.