Hacker News Reader

Comment by kdrag0n | Hacker News Reader

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

Source code: 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.

View on HN

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-change...

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).

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.

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.

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.

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.

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.

200ms is really, really slow. You almost certainly type familiar words faster than at 5cps. You'd notice and feel it, even if you don't. The thresholds are obviously different for what one typically perceives as slow or insufficiently responsive but at 200ms, almost everything stops feeling responsive.

The exact number really isn't the point. The point is if the terminal emulator is 1% of that 200ms (or 100, or whatever), then who gives a shit. You should be buying a better monitor first.

I don't think the terminal emulator matters that much below some number, it's just that you picked a really high number and that the perception of slowness is neither linear nor the same across types of activities. I think this is generally a little bit of a weakness in the article itself.

Some of us love CLI programs or using ncurses. Rougelike video games which can be played in a terminal (nethack) would profit heavily from a fast terminal

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.

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/

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.

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

Big Sur: https://i.imgur.com/R5dlzdj.png

rdar://FB8901170 if any apple employees happen to see this :)

Huh? Terminal.app is one of the fastest ones. iTerm2 is much slower in comparison.

URxvt on a 144hz gaming monitor is excellent.

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/

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

This is an option in developer settings for androids, it does feel very nice

I looked in the dev settings but could not find it? What's the exact name of the option?

I think it's Window Animation Scale, Transition Animation Scale and Animation Duration Scale.

Thanks

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

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_...

Or if Vulkan is more your jam, doable with: 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... )

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.

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.

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

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/1mahGpTKZLgKpaBDvcNR7...

Thank you!

Those Pixel 5 measurements are impressive if it’s a stock Android app.

Reply on news.ycombinator.com