12 ms·

It's worth noting that it's still possible to achieve low latency with modern hardware and even software to some extent, even with all the input filtering on to

It's worth noting that it's still possible to achieve low latency with modern hardware and even software to some extent, even with all the input filtering on touchscreens. The modern GPU rendering stack won't be able to do it, but I was able to do it in software without giving up the Linux kernel, IRQs, or the input stack. My experiment got down to ~10 ms average tap latency on a 60 Hz phone with a touchscreen scanning at 240 Hz: https://twitter.com/kdrag0n/status/1291213993219039232 https://twitter.com/kdrag0n/status/1291213993219039232 Source code: https://github.com/kdrag0n/touchpaint https://github.com/kdrag0n/touchpaint I have to say that writing on phones really feels much more interactive and natural when the latency is so low. I don't personally feel like these ranges of latency are that big of a deal on desktop computers where input is indirect, but it feels much more significant on phones where your interactions are right underneath your finger.

nomel 6y ago
The newest Apple Pencil is apparently around 9ms [1]. It really does fool your brain into thinking something is coming out of the tip. [1] https://www.macworld.com/article/3402336/apple-pencil-changes-and-improvements-in-ipados-13.html https://www.macworld.com/article/3402336/apple-pencil-change...
- sneak 6y ago
  If only they cared about such things for Terminal.app, so we didn't have the extra step of installing Alacritty on every single machine to improve the situation (and not to anywhere near 9ms, even).
  - sushisource 6y ago
    I've always found this a bit funny - why are people so concerned with input latency at the terminal? (I get why I care with a phone, or gaming). It's not like anyone's typing hundreds of characters a second. I use Alacritty, but mostly because I like the way it's config file works and it does nice font rendering. The latency thing barely even registers.
    - sneak 6y ago
      The same reason people are concerned with input latency when scrolling on a touchscreen. Lag is annoying, and the less you have, the more satisfying it is to use the device. Latency is detectible on even a single character, "hundreds of characters per second" has nothing to do with it. It's the same reason I'm not a big fan of mushy keyboards, or having to ssh between continents.
      - sushisource 6y ago
        Sure, maybe I need to add "within reason". I agree I want my keystroke to appear reasonably quickly, let's say under 200ms to fit some of the stuff in the post. Alacritty used to make kind of a big deal of these "benchmarks" on it's main page, and they don't any longer because the software improvements in the terminal are likely completely overwhelmed by whatever keyboard/monitor/OS you happen to be using. That's the point. If you really care about this stuff, the terminal isn't exactly the place to go improve stuff unless it was way worse than it should've been in the first place.
        arghwhat 6y ago
        Also note that alacritty's benchmark are throughput oriented, not latency oriented. The benchmarks measure how fast it can tear through data, not how quickly pixels change on screen. But, rendering the entire terminal buffer is slightly overkill when only a few pixels changed, and the time it takes can end up significant on weaker devices driving high resolution displays. As a result, Alacritty doesn't have the best "time to light" performance, and there have been long debates in the issues about it.
        sneak 6y ago
        200ms is a lot of lag. When trying to hjkl in to a specific character on the screen (yes, I know I should be using the 'f' verb more) that can add up quick.
        deleted 6y ago
        [deleted]
        6y ago
  - jancsika 6y ago
    At least for me, the terminal is the only place where latency is tolerable on underpowered, crappy machines. This is because my keyboard input stream will always trigger behavior deterministically in the terminal.
  - matthewmacleod 6y ago
    Isn't Terminal.app famously pretty speedy compared with most other terminal emulators? In fact, there's a link from this article to another of Dan's posts that's precisely about terminal performance - https://danluu.com/term-latency/ https://danluu.com/term-latency/ It's a few years old now so I've no doubt that Alacritty's performance has improved, but I'm suspicious of the idea that Terminal.app is noticeably slow.
    - jd3 6y ago
      I've always loved the low latency of Terminal.app (particularly over iTerm2, which I find unusable), but recently noticed that it has gotten a little worse in Big Sur now that the "Antialias Text" option is broken on non-retina displays. I assume the extra forced compositing/rendering/whatever being imposed by antialiasing is to blame, though I could be wrong. Catalina: https://i.imgur.com/G66HpJ6.png https://i.imgur.com/G66HpJ6.png Big Sur: https://i.imgur.com/R5dlzdj.png https://i.imgur.com/R5dlzdj.png rdar://FB8901170 if any apple employees happen to see this :)
  - coldtea 6y ago
    Huh? Terminal.app is one of the fastest ones. iTerm2 is much slower in comparison.
  - p1necone 6y ago
    URxvt on a 144hz gaming monitor is excellent.
    - tutfbhuf 6y ago
      URxvt is fast, but still has a mean input latency of 18.3 ms. Try Xterm it only adds 1.7 ms to the stack. I find the difference very noticeable. I switched from URxvt to Xterm a few years back, although I had to give up on proper UTF-8 glyph rendering. Low latency is important for me, because I use Vim inside Tmux inside Xterm inside Xorg and latencies add up. https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/
Aaronstotle 6y ago
There was an iOS 9 glitch that disabled all animations, and it was so satisfying to open apps and have them show up immediately. Made the phone feel super fast
- thatguy0900 6y ago
  This is an option in developer settings for androids, it does feel very nice
  - cassepipe 6y ago
    I looked in the dev settings but could not find it? What's the exact name of the option?
    - joelwilliamson 6y ago
      I think it's Window Animation Scale, Transition Animation Scale and Animation Duration Scale.
      - cassepipe 6y ago
        Thanks
- highmastdon 6y ago
  There’s still an option in accessibility to “Reduce Motion”. It does feel slightly quicker. But most animations are changed by a less visually impactful fade
bufo 6y ago
How do your flutter and Android apps compare by the way?
- kdrag0n 6y ago
  They both have much higher tap latency due to the Android graphics stack. The difference in drag/scroll latency feels even higher, but I don't know how to measure that quantitatively without special equipment. Example of ROG Phone II results: Kernel module, display running at 60 Hz: 10 ms Android, 120 Hz display: 32 ms Flutter, 120 Hz display: 30 ms They're only this close because Android gets 2x the refresh rate here, but it's still 3x slower. Running list of latency tests on many different phones: https://docs.google.com/spreadsheets/d/1mahGpTKZLgKpaBDvcNR7qFFexyGKqct3V0btqzNB7q0/edit https://docs.google.com/spreadsheets/d/1mahGpTKZLgKpaBDvcNR7...
  - bufo 6y ago
    Thank you!
  - bufo 6y ago
    Those Pixel 5 measurements are impressive if it’s a stock Android app.
kllrnohj 6y ago
You don't need to jump through all the hoops you did. Many Android devices, high end ones anyway, support front buffer rendering via public APIs, such as through this extension: https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_mutable_render_buffer.txt https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_... Or if Vulkan is more your jam, doable with: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_shared_presentable_image.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions... And then "no-latency" input events can be done via View#requestUnbufferedDispatch ( https://developer.android.com/reference/android/view/View?hl=en#requestUnbufferedDispatch(int) https://developer.android.com/reference/android/view/View?hl... ) I'm sure there's then some way to achieve front-buffer rendering in a software rendered pipeline as well to cut out the GPU latency & avoid tile-based artifacts.
- kdrag0n 6y ago
  Interesting, I might give those rendering APIs a shot. Thanks for the tips. I did try requestUnbufferedDispatch though, and it didn't make a noticeable visual difference, but I need to measure it to make sure.

nomel 6y ago

The newest Apple Pencil is apparently around 9ms [1]. It really does fool your brain into thinking something is coming out of the tip. [1] https://www.macworld.com/article/3402336/apple-pencil-changes-and-improvements-in-ipados-13.html https://www.macworld.com/article/3402336/apple-pencil-change...

sneak 6y ago
If only they cared about such things for Terminal.app, so we didn't have the extra step of installing Alacritty on every single machine to improve the situation (and not to anywhere near 9ms, even).
- sushisource 6y ago
  I've always found this a bit funny - why are people so concerned with input latency at the terminal? (I get why I care with a phone, or gaming). It's not like anyone's typing hundreds of characters a second. I use Alacritty, but mostly because I like the way it's config file works and it does nice font rendering. The latency thing barely even registers.
  - sneak 6y ago
    The same reason people are concerned with input latency when scrolling on a touchscreen. Lag is annoying, and the less you have, the more satisfying it is to use the device. Latency is detectible on even a single character, "hundreds of characters per second" has nothing to do with it. It's the same reason I'm not a big fan of mushy keyboards, or having to ssh between continents.
    - sushisource 6y ago
      Sure, maybe I need to add "within reason". I agree I want my keystroke to appear reasonably quickly, let's say under 200ms to fit some of the stuff in the post. Alacritty used to make kind of a big deal of these "benchmarks" on it's main page, and they don't any longer because the software improvements in the terminal are likely completely overwhelmed by whatever keyboard/monitor/OS you happen to be using. That's the point. If you really care about this stuff, the terminal isn't exactly the place to go improve stuff unless it was way worse than it should've been in the first place.
      - arghwhat 6y ago
        Also note that alacritty's benchmark are throughput oriented, not latency oriented. The benchmarks measure how fast it can tear through data, not how quickly pixels change on screen. But, rendering the entire terminal buffer is slightly overkill when only a few pixels changed, and the time it takes can end up significant on weaker devices driving high resolution displays. As a result, Alacritty doesn't have the best "time to light" performance, and there have been long debates in the issues about it.
      - sneak 6y ago
        200ms is a lot of lag. When trying to hjkl in to a specific character on the screen (yes, I know I should be using the 'f' verb more) that can add up quick.
      - deleted 6y ago
        [deleted]
      - 6y ago
- jancsika 6y ago
  At least for me, the terminal is the only place where latency is tolerable on underpowered, crappy machines. This is because my keyboard input stream will always trigger behavior deterministically in the terminal.
- matthewmacleod 6y ago
  Isn't Terminal.app famously pretty speedy compared with most other terminal emulators? In fact, there's a link from this article to another of Dan's posts that's precisely about terminal performance - https://danluu.com/term-latency/ https://danluu.com/term-latency/ It's a few years old now so I've no doubt that Alacritty's performance has improved, but I'm suspicious of the idea that Terminal.app is noticeably slow.
  - jd3 6y ago
    I've always loved the low latency of Terminal.app (particularly over iTerm2, which I find unusable), but recently noticed that it has gotten a little worse in Big Sur now that the "Antialias Text" option is broken on non-retina displays. I assume the extra forced compositing/rendering/whatever being imposed by antialiasing is to blame, though I could be wrong. Catalina: https://i.imgur.com/G66HpJ6.png https://i.imgur.com/G66HpJ6.png Big Sur: https://i.imgur.com/R5dlzdj.png https://i.imgur.com/R5dlzdj.png rdar://FB8901170 if any apple employees happen to see this :)
- coldtea 6y ago
  Huh? Terminal.app is one of the fastest ones. iTerm2 is much slower in comparison.
- p1necone 6y ago
  URxvt on a 144hz gaming monitor is excellent.
  - tutfbhuf 6y ago
    URxvt is fast, but still has a mean input latency of 18.3 ms. Try Xterm it only adds 1.7 ms to the stack. I find the difference very noticeable. I switched from URxvt to Xterm a few years back, although I had to give up on proper UTF-8 glyph rendering. Low latency is important for me, because I use Vim inside Tmux inside Xterm inside Xorg and latencies add up. https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/

Aaronstotle 6y ago

There was an iOS 9 glitch that disabled all animations, and it was so satisfying to open apps and have them show up immediately. Made the phone feel super fast

thatguy0900 6y ago
This is an option in developer settings for androids, it does feel very nice
- cassepipe 6y ago
  I looked in the dev settings but could not find it? What's the exact name of the option?
  - joelwilliamson 6y ago
    I think it's Window Animation Scale, Transition Animation Scale and Animation Duration Scale.
    - cassepipe 6y ago
      Thanks
highmastdon 6y ago
There’s still an option in accessibility to “Reduce Motion”. It does feel slightly quicker. But most animations are changed by a less visually impactful fade

bufo 6y ago

How do your flutter and Android apps compare by the way?

kdrag0n 6y ago
They both have much higher tap latency due to the Android graphics stack. The difference in drag/scroll latency feels even higher, but I don't know how to measure that quantitatively without special equipment. Example of ROG Phone II results: Kernel module, display running at 60 Hz: 10 ms Android, 120 Hz display: 32 ms Flutter, 120 Hz display: 30 ms They're only this close because Android gets 2x the refresh rate here, but it's still 3x slower. Running list of latency tests on many different phones: https://docs.google.com/spreadsheets/d/1mahGpTKZLgKpaBDvcNR7qFFexyGKqct3V0btqzNB7q0/edit https://docs.google.com/spreadsheets/d/1mahGpTKZLgKpaBDvcNR7...
- bufo 6y ago
  Thank you!
- bufo 6y ago
  Those Pixel 5 measurements are impressive if it’s a stock Android app.

kllrnohj 6y ago

You don't need to jump through all the hoops you did. Many Android devices, high end ones anyway, support front buffer rendering via public APIs, such as through this extension: https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_mutable_render_buffer.txt https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_... Or if Vulkan is more your jam, doable with: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_shared_presentable_image.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions... And then "no-latency" input events can be done via View#requestUnbufferedDispatch ( https://developer.android.com/reference/android/view/View?hl=en#requestUnbufferedDispatch(int) https://developer.android.com/reference/android/view/View?hl... ) I'm sure there's then some way to achieve front-buffer rendering in a software rendered pipeline as well to cut out the GPU latency & avoid tile-based artifacts.

kdrag0n 6y ago
Interesting, I might give those rendering APIs a shot. Thanks for the tips. I did try requestUnbufferedDispatch though, and it didn't make a noticeable visual difference, but I need to measure it to make sure.