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.<p>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.
The surprising thing here is that this is the <i>Ubuntu</i> 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 <i>then</i> it gets rendered.<p>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.<p>(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.)
If anyone else is curious about measuring things like this, try the <a href="https://isitsnappy.com/" rel="nofollow">https://isitsnappy.com/</a> app on a modern phone.<p>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.<p>This really surprises me.
> 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.<p>You could say that a longer version of that answer is "Text Rendering Hates You": <a href="https://gankra.github.io/blah/text-hates-you/" rel="nofollow">https://gankra.github.io/blah/text-hates-you/</a>
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 <i>does</i> sound like it would be a good challenge.
> 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.<p>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.
WSL terminal is garbage. Here's what irks me:<p>* 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).<p>* I type in "clear && ls" and hit enter.<p>* 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).<p>* I press up (to step backward through my command history) and all the text vanishes again.<p>The only workaround I have is to run something like tmux, which is somehow smart enough to render the text on-screen.
I'm a heavy WSL user, ever since I switched to Windows last year (after using MacOS for 6 years, and Linux before that).<p>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.
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.<p>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.
Discussed earlier this year: <a href="https://news.ycombinator.com/item?id=19471857" rel="nofollow">https://news.ycombinator.com/item?id=19471857</a><p>I feel like there was a larger discussion too, but can't find it. Anyone?
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.
Qt KTerm, and VTE both supported complex typographies close to 20 years ago and nevertheless achieve similar performance.<p>It is a testament just how much behind times MS was up until recently.
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).
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.<p>with alot of help from wsltty and autohotkey, i am quickly approaching some sort of windows+linux singularity event, <a href="https://i.imgur.com/cXykxPN.png" rel="nofollow">https://i.imgur.com/cXykxPN.png</a>
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.
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.
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.<p>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.)