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.
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.
> 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.
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.
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!
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.
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.
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.
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.
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
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.
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.
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:
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.
The surprising thing here is that this is the Ubuntu terminal. Indeed, each keystroke goes through the input driver, to USER32, through the console code, to the terminal process in question. But then it goes through a virtual input device, across the VM boundary (which, on Windows is a VM exit plus an entry), through the Linux input driver, into dash (or whatever Ubuntu uses these days), and then all the way back out again, and then it gets rendered.
The fact that this whole dance is faster than notepad.exe suggests that Linux is doing pretty well, that MS’s hypervisor stack is performing well, and that the fancier MS frameworks are really quite slow.
(To be fair, the GNOME Wayland stack has recently been upgraded from awful to sort-of-decent latency-wise. It’s all too easy to design a system where latency wasn’t a primary consideration from day 1 and to have a very hard time improving latency after the fact.)
I think most of the latency between key press and rendering to screen is in the layout / drawing phase.
Forwarding a few function calls is usually pretty fast, the text layout and rendering part is what is slow. Especially since many UI frameworks don't render individual characters; you may end up redrawing a full line or more for every keystroke. (I only have experience with macOS / Cocoa rendering, and I was surprised how slow it is compared to all other things my code does)
All of the actual work can easily happen in under a millisecond. What makes input to screen output slow is anything asynchronous - polling (on the input side, e.g. in the USB protocol itself - USB to PCI uses interrupts!) and waiting for the next frame on the output side. Let's say the console waits for vsync to render its next frame, then the compositor grabs it and renders it in the next frame. That is one frame of gratuitous latency.
Then there's also the input lag of your monitor too which is really important.
A lot of monitors have really bad input lag, in the 50-60ms range and it's highly variable. This spec is also not usually listed by the manufacturer either and it's not the same thing as response time which is typically 1-10ms in most modern LCDs.
Your monitor's input lag plays a very big role in how fast key presses are perceived because ultimately what makes something feel fast and snappy requires an end to end measurement of you pressing a key and then your eyeballs being able to register it.
The monitor I picked has about 10-14ms of input lag which is very good compared to the average. That's running at 2560x1440 (60hz) at 1:1 scaling too.
I still use the same monitor today and I would buy it again today if I were thinking about upgrading. Although I kind of regret writing that blog post now because the monitor is almost twice as expensive today as it was 3 years ago.
> Physical size doesn’t constitute how much you can fit on a monitor. For example my mom thinks that a 25” 1080p monitor is going to let her fit more things on her screen than a 22” 1080p monitor. Don’t be my mom!
> The only thing that matters for “fitting more stuff on the screen” is the resolution of the monitor.
This is only true under the assumption that your eyes have infinite resolution. In the more likely case that they don't, the larger size of the pixels at a higher physical screen size means you need fewer pixels, with the result that you can indeed fit more stuff on the screen at the same resolution.
It's not just eye resolution, its how the application is designed. An older WinForms application will have very compact ui and mad information density, but some modern web apps will dedicate an entire 1080p window to display 1 icon and two buttons.
I would say that combined with DPI scaling, his port provides a reasonable rule of thumb.
One frame of latency is not gratuitous; it's perfectly reasonable to not draw directly "ahead of the beam" and instead double-buffer. Otherwise you get a lot of tearing.
I very much doubt the console is watching vsync either.
The extra frame that I mean is: console renders, vsync, compositor grabs it and renders, vsync. That is what happens on X11 with compositing AFAIK. Only one frame time / one vsync is really required before you consider specifics of the software involved. I've read somewhere that Windows also has an extra frame of latency for similar reasons as X11.
In terms of key press latency it makes no difference. Both the old and new MS terminal have about the same input latency.
The problem is, the MS terminal doesn't work well with tmux which is a 100% deal breaker.
WSL2's I/O is better but that's out of scope for this discussion and also a pretty sketchy thing to run as of today since it requires opting into the insider's release of Windows which has very questionable telemetry requirements.
Depends on the operation in question. Direct syscalls should be faster, but there are some big differences between the NT and Linux kernels. You end up getting all the poor performance areas of BOTH. That, and HyperV has an extremely fast lightweight VM mode for particular hardware. For example, running containers on HyperV actually runs them with VM level isolation, a la Kata containers... and at competitive speeds.
An example of the worst of both worlds result is the filesystem. In the NT kernel, every filesystem call goes through a series of Filters: any program can provide filters for given file types. Filters can do anything, from antivirus programs scanning the file on access, to Notepad adding itself to the Context Menu as an "open with Notepad" item. This makes filesystem access - even metadata checks - very time expensive on Windows. On Linux, we keep file metadata in memory, which is memory expensive, but it makes certain filesystem operations very fast. The result of mapping one onto the other is a combined filesystem operation which is memory expensive AND slow.
So for example, on WSL 1 (mapped syscalls), using a git repo of any size is impossibly slow... on the order of 10 seconds to get a git status for a work project. But on WSL2, the same syscalls live entirely inside the VM and are almost native fast.
If anyone else is curious about measuring things like this, try the https://isitsnappy.com/ app on a modern phone.
It’s real nice to have some competition for macOS on this front — and especially when it moves out of terminals into related tools like editors (VSCode was close to Terminal.app the last time I measured while e.g. Atom was fully an order of magnitude worse). This is a frictional productivity cost which most people discount because it’s not as obvious.
I just tried it and I'm blown away and confused: why is Windows Terminal faster in an ubuntu tab (WSL1, in my case) than in a cmd.exe / powershell tab? I mean the exact same terminal window. Three tabs side by side. The ubuntu one is instantaneous and the others have short but noticeable lag.
> Of course this also means that we have trade offs. We don't support fully international text like pretty much every other application will. RTL? No go zone right now. Surrogate pairs and emoji? We're getting there but not there yet. Indic scripts? Nope.
I'm curious how alacritty compares to it. The alacritty devs basically consider another terminal app rendering faster than them to be a bug on their part ;-) But it does sound like it would be a good challenge.
> I'm curious how alacritty compares to it. The alacritty devs basically consider another terminal app rendering faster than them to be a bug on their part
Note: Alacritty prides itself on fast rendering speed, but not necessarily on low latency[0]. I'm a happy Alacritty/Linux user, but I'm not sure it would win on this benchmark.
Alacritty has kind of a lot of input latency, it's noticeably worse than wsltty and the default WSL terminal -- at least back when I checked it a year ago.
I think some work has been done to improve it, but at this point IMO if you're on Windows then wsltty is as good as it gets for a general purpose terminal. If you're on Linux, xterm is top notch.
I don't know, I've got two panes here opened next to each other (tiled/xmonad) with xterm and alacritty, and I've been typing in those for the last 5min, and I really can't tell the difference (my monitor has 5ms latency).
I use kitty and alacritty interchangeably on Linux/X and I don't literally can't tell the difference between the two. Sometimes I forget which one I'm using. Using pretty much anything else it's very obvious.
> Of course this also means that we have trade offs. We don't support fully international text like pretty much every other application will. RTL? No go zone right now. Surrogate pairs and emoji? We're getting there but not there yet. Indic scripts? Nope.
I find it interesting that Even though I don’t care about any of the above features, I still pay for them working with text in other applications. They are a constant tax on latency. It would be great if applications had a “ascii” mode and a “full” mode. You can take the performance or the features, but you can’t have both.
I could be wrong, but I think the payment for one pays for the others. International text is one of those "a large portion of the world wants this" sorts of features. Once you've gotten that, emojis sort of come along for the ride.
* I click on the icon and I get a terminal up (nevermind that it doesn't accept focus on startup, so I start typing and the characters keep going to my task bar).
* I type in "clear && ls" and hit enter.
* My line of text vanishes and I'm left with a completely black terminal. If I scroll up with the mouse-wheel I can see what I should have seen (the output of ls).
* I press up (to step backward through my command history) and all the text vanishes again.
The only workaround I have is to run something like tmux, which is somehow smart enough to render the text on-screen.
I agree, been trying to make this setup work for over a year now because I use Windows at work for a few things here and there but it's just not worth it really...
You would do much better to install Linux and virtualize windows, then you get the best of both worlds. it's great that windows decided to add a terminal after every other OS has had it for decades but I think this thread is a bit like having rose colored glasses on top of your drunk goggles because WSL and Windows terminal are still an ocean away from a usable low latency terminal environment compared even to OS/2 if we're being brutally honest...
I'm a heavy WSL user, ever since I switched to Windows last year (after using MacOS for 6 years, and Linux before that).
I must agree that typing is pretty responsive compared to other windows applications, but still nothing near the native experience. I also run clear linux natively on my laptop, and typing in that terminal is just faster.
This is great to see. My experience with windows in general is that the typing latency is usually very bad compared to ubuntu. I can literally notice the lag. Plus some apps have these awful typing animations which make typing feel like wading through mud.
I didn't realize how bad input latency had gotten in general until recently when I needed to boot directly into a terminal. Sometimes I could swear the character appears on the screen before I even hit the key. It's a weird feeling, but I would like more of it.
A few months ago I was installing Debian on a desktop, and there's this one part during the installer where it prompts you for some information before your desktop is ready to go.
The input processing was so fast it was stupid. It somehow felt even faster than xterm which is already so much better than just about any app on any OS.
Correct me if I'm wrong but I've been struggling to really nail down my development process of linux software on Windows, and based on my readings, a lot of articles state that applications perform far better on traditional hypervisors like VMWare and VirtualBox than WSL.
I mean it may be great that the WSL terminal feels good, but if my program takes 2-5x slower in WSL for testing, I'm still going to opt for a hypervisor.
I really wish there was a way for the browser to blit pixels to the screen in the shortest amount of time possible. Like talking directly to the GFX hardware using a restricted API like the Canvas 2d context.
I don't have high hopes for something designed by committee.
The Chromium team are experimenting with Low-latency (desynchronized) canvas, although I haven't been able to measure any differences in latency, the only difference is that desyncronization will cause some render issues.
I guess latency is a "full stack" problem where you have to design everything with low latency in mind. eg. keyboard, keyboard driver, render framework, gfx driver, and screen.
There is nothing called Windows 7.1. Windows 7 extended support ends January 14, 2020. Windows 8.1 won't end its extended support until January 10, 2023.
we even have WSL. I think someone in upper management pressured IT to either upgrade or start supporting Ubuntu laptops and that kind of got them going.
is it because it's distributed through the store or because you're on a too old version of Windows? In the first case, you could probably build it yourself and install it on your own
I'd recommend giving it another go and digging into the documentation. They've made the UX much less clunky and support panes now as well as tabs, proper copy/paste etc. My only wish is modal keybindings but if I cared enough I'd send a PR for them.
It was extremely barebones six months ago but it's come a long way, and faster than anything else I've tried.
From my perspective though, libVTE performance is terrible. On modern systems it may not be a concern, but on some of my older systems VTE terminals are unusable for any significant throughput of text (while xterm and rxvt run like greased lightning).
While I've never benchmarked them, the original NT console running on that same old hardware feels roughly in the same class as xterm. Per the dev response on the Issue, it sounds as though not too much has changed under the hood. If adding support for such typographies would put it in the same performance class as VTE, I'd consider that a serious regression (at least an order of magnitude).
Or are you saying that the Windows terminal has already regressed that far?
I often find myself using cmd (the old terminal prompt that is default WSL) on windows. It's not perfect, but I found a patch to enable ANSI color support and it's so much better latency-wise. I hope others work as well in the future; the fancy new much-lauded windows terminal, on the other hand, is to horribly latent for comfortable use (as are many others).
Yes, without exception. It's less noticeable on today's powerful systems, but it's still true. Text mode is just faster than graphics mode, at least on any system where I've used both.
wsltty is the most underrated app i use on the regular. i was pumped about the new microsoft terminal for all of 5 seconds, then i used it, what a letdown.
with alot of help from wsltty and autohotkey, i am quickly approaching some sort of windows+linux singularity event, https://i.imgur.com/cXykxPN.png
Too bad it doesn’t handle Unicode. Also it’s a shame that it doesn’t have tabs or any hot keys for increasing productivity. It’s really a good shell if you don’t have work to do.
Yeah, that's why I switched to wsltty many many months ago. It has comparable input latency, good hotkey support, clickable URLs, unicode support, etc..
I was excited about WSL when I first heard about it. But that excitement quickly faded when I realized most real apps, such as gcc, don't work under it. The best way to get a Linux prompt on Windows is to use Docker. Use the -v option to share your drive.
Think it'd be worth trying on wsl2 again. The first version was too slow to use, but I am loving wsl 2 now. The integration between windows and the wsl2 vm is a lot more seamless than it used to be. You can navigate the c drive from the wsl shell and also do stuff like `explorer.exe .` to open a windows folder app in the current wsl directory. The vscode integration is amazing as well. After using a mac for many years, it took me about a week to be sold on using a windows laptop from here on out.
It's funny, because I quit using WSL because of high latency. I can't say input latency is a big deal to me. I can always wait 100ms for the buffer to catch up with my typing.
But when most commands have 500ms of overhead that is another story. My Xfce4 terminal running in a Hyper V VM is so much faster. If only there were seamless copy-paste. (Incidentally, I tried using Virtualbox but the latency there is more like WSL.)
You could always run VcXsrv to act as an X server.
Then you can launch GUI apps through your Hyper-V based VM (or any hypervisor).
It has seamless clipboard sharing that works out of the box once you enable the option.
I even went as far as running i3wm through VcXsrv for a while but ultimately gave that up since multi-monitor support didn't really work, but if you have 1 monitor it was actually quite usable.
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.