[nickjj]

Author of the GitHub issue here. I was surprised to see this title, because I thought "holy cow, finally someone else appreciates low input latency" and then I realized it was my issue haha.

By the way, wsltty 3.x also has excellent input latency now too. I've been using it for quite a while now with terminal Vim in WSL and it's about 90% as good as xterm on native Linux in terms of latency. wsltty also has no issues with tmux where as the MS terminal (both old and new) have severe issues with tmux.

[bhauer]

Thank you for providing the praise to the Windows Terminal team many of us know they deserve, allowing us to just click the thumbs-up response on GitHub.

I truly wish more modern software were capable of reaching this level of latency performance. I understand the response provided by "miniksa" at GitHub, but I don't feel satisfied by it. The maintainers of the frameworks that are described as adding so much latency should make a concerted effort to minimize that latency. We know from experience (see ASP.NET Core) that huge strides can be made in performance (both measured as throughput and latency) and that it is massively rewarding. It requires effort, but the payoffs are real.

I fear computer science is often encumbered by a corrosive culture of "good enough" with respect to performance. We have a lot of baggage and urban myths about performance, from maxims about optimization handed down from the first acolytes of computer science, to modern opinions about UX that over-emphasize simplicity, to a repertoire of clever psychological countermeasures for under-performance such as animation. It's a shame that more people don't appreciate how much more enjoyable computing is when latency is nearly zero.

Obviously orders of magnitude matter. The change from 1000ms to 100ms is more significant than a change from 100ms to 10ms. But we cannot diminish that latter change and we should not accept 100ms as good enough. Improving from 100ms to 10ms is still huge and some of us deeply appreciate it.

[acdha]

> I fear computer science is often encumbered by a corrosive culture of "good enough" with respect to performance. We have a lot of baggage and urban myths about performance, from maxims about optimization handed down from the first acolytes of computer science, to modern opinions about UX that over-emphasize simplicity, to a repertoire of clever psychological countermeasures for under-performance such as animation. It's a shame that more people don't appreciate how much more enjoyable computing is when latency is nearly zero.

I wouldn't blame this on computer science: it's really just a long way of saying you get what you measure. It's not that computer scientists don't care about performance, or that human factors / UX isn't an entire field, but simply that most projects don't set performance goals or prioritize them and unsurprisingly most time is spent on the things which are used to judge someone's job performance.

This is especially true when you see how many issues are shared across teams — in this case talking about Windows it's important to remember that during the Ballmer lost years, Microsoft used stack ranking to force managers to categorize a set fraction of people as low performances and reportedly those rankings heavily favored new features over maintenance improvements. In an environment like that, if the change requires coordination across teams it probably just isn't going to happen unless someone very senior makes it a business priority.

[saagarjha]

> I fear computer science is often encumbered by a corrosive culture of "good enough" with respect to performance.

I feel that's more of a "software engineering" mindset.

[meatcar]

I just want to emphasize that wsltty is the only well-behaving terminal currently available for WSL. It's the only one that supports mouse interaction in a terminal like scrolling/resizing panes in tmux/vim, unlike any Microsoft solution.

If you're using WSL on a regular basis, I highly recommend it. Its a huge quality-of-life improvement.

[DHowett]

I am fairly certain that the inbox console host supports mouse interaction (with WSL and anything else that uses VT mouse mode). As the engineering lead for the console and terminal projects, though, I’d love to know how else we can improve!

[nickjj]

I noticed the same issues with tmux and the new MS terminal. The events got completely absorbed.

Also there were a bunch of "crazy" display issues, such as when minimizing the window about ~30% of the time the tmux status bar would become hidden.

Or after I exit tmux or even Vim sometimes without tmux, the terminal's background color would turn yellow (but not the entire terminal's background, just the characters where input / output would be legally able to be placed).

All of these things were discovered within about 2 minutes of using it, so these aren't edge cases. They happened very frequently, and things like the mouse just didn't work all the time.

Edit:

I just put together a 10min video showing a few of these display issues with the new MS terminal at: https://www.dropbox.com/s/puzbfs6ws4p8v7a/ms-terminal.mp4?dl...

The yellow screen issue never happened on video, maybe they fixed that but within 1 minute of using the terminal I found 2 new display bugs that weren't there when I tried it months ago.

Also sorry about the quality of the video. Drop box re-encodes videos at 720p (I recorded it at 1080p) and it looks like they are really strict with bitrates too. It looks slightly better than a potato, but you can still make out the display issues.

[zamadatix]

I'm not a terminal wizard but there is one bug that constantly happens in my workflow I'm not sure how to report: if I start a powershell session then ssh into a network switch and then access the serial TTY of a kvm guest running on the switch it sets the terminal size to particular dimensions (as expected). If I exit the serial connection then sometimes the terminal is never restored to normal size, even if I exit ssh back to the original powershell session.

Like I said very easy for me to reproduce but probably hard for you guys and I'm not sure what is breaking or how to capture the session to submit a bug.

.

Also it'd be amazing if profiles could include panes. I find myself almost in need of making an autohotkey script to break the terminal into 4 panes and launch particular ssh commands.

[andrewmackrodt]

wsltty loaded via ConEmu is the only acceptable terminal combination I've found for Windows, with support for mouse events, scrollwheel and remote terminal resize detection, e.g. ssh into another box and run a program like htop. I last tried microsoft/terminal about 6 months ago and found it incredibly broken.

[joshspankit]

Another vote for low-latency here.

It’s tempting to create a YouTube channel dedicated to showing input latencies for common tasks. Question is: how do you make sure no one is cheating?

[cjbprime]

Use a measurement device and show it in the video.

Like the 1000fps camera used in https://danluu.com/input-lag/

[joshspankit]

Where this would be really transformative is if anyone could submit a video and have it verified. If they set up their own slo-mo capture they could just as easily record a sped-up screen capture.

There's definitely a way out by requiring that the tests are reproducible in a 'lab', but that throws out results from machines the lab doesn't have access to

[rwerkjlkjweq]

Can you post your computer specs?

Because it's impossible for me to see any difference between the WSL terminal and Notepad. I can see a tiny difference compared with Electron apps, but I really need to concentrate to see it.

My computer is no rocket, is a higher-end desktop from 6 years ago.

[nickjj]

Mine is a ~6 year old i5 quad core desktop. A complete list of hardware can be found here: https://nickjanetakis.com/blog/the-tools-i-use#computer-desk...

If you can't notice it much, perhaps your monitor has really bad input lag and it's overtaking any difference between terminals. My monitor has very low input lag (about 13ms) but most monitors have 50-60ms or worse.

There's another comment in this thread where I go into more details about that and how it plays a big difference in being able to perceive input latency when typing.

[japhyr]

Your post How to Pick a Good Monitor for Software Development was really helpful when I was upgrading my home office this fall. Thank you, and anyone else who hasn't specced out a monitor in a while might find it helpful as well:

https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo...

[z3t4]

Try changing the theme to basic. In Windows 10, using the default theme added about 50ms in latency.

[CalChris]

There has been some discussion lately about how latencies have increased over the decades.

https://news.ycombinator.com/item?id=15485672

[Dolores12]

How do you measure input latency?

[nickjj]

In the tests I've done on most terminals it was an organic process.

I simply typed into the terminal and let my brain decide. I spent about an hour just flipping between different terminals / programs and doing a bunch of different types of typing tests. It was very very clear and repeatable to do a "better or worse?" test between them.

Typing fast, typing slow and also just holding down the key (this made the most noticeable difference). Terminals that have low input latency will appear to spit out characters liquid smooth if you hold down the key.

I also talked to some friends who use Windows and we came to the same conclusion in a blind test.

For measuring the latency numbers themselves, it was just making a best estimate based on how I perceive those values. I don't think the numbers matter as much as the "this feels better" or "this feels worse" test since in the end that's the deciding factor.