3 ms·

I would like to try a 1 kHz display. I can definitely tell the difference between 120 and 240 Hz for mouse pointer motion. The motion blur tests mentioned in th

I would like to try a 1 kHz display. I can definitely tell the difference between 120 and 240 Hz for mouse pointer motion. The motion blur tests mentioned in the article make it obvious as well. And Microsoft research has shown that when using direct touch interaction people can perceive latency all the way down to 1 ms. https://www.youtube.com/watch?v=vOvQCPLkPt4 https://www.youtube.com/watch?v=vOvQCPLkPt4 Also an underrated feature of high frame rate is that it's a universal fix for poorly written software with multiple frames of latency. An application with 10 frames of latency will be faster on a 1 kHz display than a perfectly coded application on a 60 Hz display.

dullcrisp 2y ago
Hmm couldn’t you just skip frames to achieve that same effect on any monitor?
- modeless 2y ago
  Well, with a latency floor at the real refresh rate. But it would be nice if OSes provided a feature like that. In general modern desktop compositors tend to go in the other direction, adding frames of latency universally to all applications.
user_7832 2y ago
Tangentially related on the topic of latency perception: Computer latency: 1977-2017 by Dan Luu I also remember an HN post where it was possible to measure latency in 2 halves of the screen, top folks were able to detect it to single digit ms. I think could see upto around 16 or 32ms on my 60hz (FW13) screen. [0] = https://danluu.com/input-lag/ https://danluu.com/input-lag/
foxhill 2y ago
> An application with 10 frames of latency will be faster on a 1 kHz display than a perfectly coded application on a 60 Hz display. thats actually not true. you seem to be implying that the best a 60hz display can manage is 16.6ms of latency. indeed that is the worst case value, but you should consider that early graphics technologies involved changing display modes mid scan. it’s actually not ridiculous to suggest that old platforms had sub-millisecond latency; they did. if the scanline was on, or just before, the line where you would interact (i.e., the prompt line), the text you enter would appear immediately. of course, “vsync”, tear free, and such like approaches “fixed” this - necessarily by adding at least a frame’s worth of latency - but also adding perceptual latency. it’s an oft-overlooked aspect of refresh rates. a 60hz CRT, without vsync, still has the lower bound of latency lower than a 120hz display. perhaps even 240hz. i’ve used two 240hz displays for years now. i’ll never go slower than that.
- IshKebab 2y ago
  I think you should assume that we aren't talking about CRTs. Come on.
  - foxhill 2y ago
    apologies, i wasn't being specific; none of what i said necessitates a CRT display, it was only as an example of how an older technology had less latency. if modern a modern 60Hz LCD/OLED display couldn't get beneath 16.6ms latency, then what exactly is tearing?
    - IshKebab 2y ago
      Hmm good point!
- modeless 2y ago
  > you seem to be implying that the best a 60hz display can manage is 16.6ms of latency Yes, if you control the whole software stack it is possible to do beam racing to get lower than one frame of latency (assuming low latency hardware for input and display panel scanout). But I'm talking about desktop/mobile applications. In general operating systems do not do this, and many actually make it impossible. Only very recently has it become possible to do beam racing in a windowed application (not using fullscreen exclusive mode) on Windows with recent graphics hardware with multiplane overlay and very, very few people have attempted to do it. I believe it is strictly impossible to do beam racing for windowed applications on macOS and Linux/Wayland. Not sure about iOS and Android.
  - foxhill 2y ago
    you don't need to "beam race" to achieve sub-frame latency - you don't need to be accurate. switching off vsync should, principally, be enough to achieve this. otherwise, yes, modern APIs go out of their way to avoid the possibility of this (the dreaded "tearing" artifacts you see from the frame buffer being changed during the transmission of the video signal to the monitor). i don't believe older techniques like you've mentioned are at all possible today, and only really made sense to talk about when analogue displays were the norm.
stavros 2y ago
Except applications don't tend to lag "for ten frames", but for "ten ms". Your application that skips ten frames at 100 Hz will skip a hundred frames at 1 KHz.
- modeless 2y ago
  It's true that some applications have input lag due to simply being slow to process input. But there are many applications that actually process input fast enough, but still have a lot of input lag because of various forms of buffering linked to frames. A typical scenario would be 1.5 frames of latency due to the desktop compositor, 2-3 frames due to buffering in the graphics API (graphics APIs optimize for throughput instead of latency by default), and 1-2 frames because the application state doesn't completely update on the same frame as the input is received. Ten frames would be unusually bad, but it can happen. It all adds up! And all of that is made faster by higher frame rates. Properly made applications can bypass most of that latency but few bother to really optimize for it, so a systemwide fix is welcome.

dullcrisp 2y ago

Hmm couldn’t you just skip frames to achieve that same effect on any monitor?

modeless 2y ago
Well, with a latency floor at the real refresh rate. But it would be nice if OSes provided a feature like that. In general modern desktop compositors tend to go in the other direction, adding frames of latency universally to all applications.

user_7832 2y ago

Tangentially related on the topic of latency perception: Computer latency: 1977-2017 by Dan Luu I also remember an HN post where it was possible to measure latency in 2 halves of the screen, top folks were able to detect it to single digit ms. I think could see upto around 16 or 32ms on my 60hz (FW13) screen. [0] = https://danluu.com/input-lag/ https://danluu.com/input-lag/

foxhill 2y ago

> An application with 10 frames of latency will be faster on a 1 kHz display than a perfectly coded application on a 60 Hz display. thats actually not true. you seem to be implying that the best a 60hz display can manage is 16.6ms of latency. indeed that is the worst case value, but you should consider that early graphics technologies involved changing display modes mid scan. it’s actually not ridiculous to suggest that old platforms had sub-millisecond latency; they did. if the scanline was on, or just before, the line where you would interact (i.e., the prompt line), the text you enter would appear immediately. of course, “vsync”, tear free, and such like approaches “fixed” this - necessarily by adding at least a frame’s worth of latency - but also adding perceptual latency. it’s an oft-overlooked aspect of refresh rates. a 60hz CRT, without vsync, still has the lower bound of latency lower than a 120hz display. perhaps even 240hz. i’ve used two 240hz displays for years now. i’ll never go slower than that.

IshKebab 2y ago
I think you should assume that we aren't talking about CRTs. Come on.
- foxhill 2y ago
  apologies, i wasn't being specific; none of what i said necessitates a CRT display, it was only as an example of how an older technology had less latency. if modern a modern 60Hz LCD/OLED display couldn't get beneath 16.6ms latency, then what exactly is tearing?
  - IshKebab 2y ago
    Hmm good point!
modeless 2y ago
> you seem to be implying that the best a 60hz display can manage is 16.6ms of latency Yes, if you control the whole software stack it is possible to do beam racing to get lower than one frame of latency (assuming low latency hardware for input and display panel scanout). But I'm talking about desktop/mobile applications. In general operating systems do not do this, and many actually make it impossible. Only very recently has it become possible to do beam racing in a windowed application (not using fullscreen exclusive mode) on Windows with recent graphics hardware with multiplane overlay and very, very few people have attempted to do it. I believe it is strictly impossible to do beam racing for windowed applications on macOS and Linux/Wayland. Not sure about iOS and Android.
- foxhill 2y ago
  you don't need to "beam race" to achieve sub-frame latency - you don't need to be accurate. switching off vsync should, principally, be enough to achieve this. otherwise, yes, modern APIs go out of their way to avoid the possibility of this (the dreaded "tearing" artifacts you see from the frame buffer being changed during the transmission of the video signal to the monitor). i don't believe older techniques like you've mentioned are at all possible today, and only really made sense to talk about when analogue displays were the norm.

stavros 2y ago

Except applications don't tend to lag "for ten frames", but for "ten ms". Your application that skips ten frames at 100 Hz will skip a hundred frames at 1 KHz.

modeless 2y ago
It's true that some applications have input lag due to simply being slow to process input. But there are many applications that actually process input fast enough, but still have a lot of input lag because of various forms of buffering linked to frames. A typical scenario would be 1.5 frames of latency due to the desktop compositor, 2-3 frames due to buffering in the graphics API (graphics APIs optimize for throughput instead of latency by default), and 1-2 frames because the application state doesn't completely update on the same frame as the input is received. Ten frames would be unusually bad, but it can happen. It all adds up! And all of that is made faster by higher frame rates. Properly made applications can bypass most of that latency but few bother to really optimize for it, so a systemwide fix is welcome.