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
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.)
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.
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 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 feel that's more of a "software engineering" mindset.
If you're using WSL on a regular basis, I highly recommend it. Its a huge quality-of-life improvement.
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?
Like the 1000fps camera used in https://danluu.com/input-lag/
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.
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 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.)
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)
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.
This really surprises me.
You could say that a longer version of that answer is "Text Rendering Hates You": https://gankra.github.io/blah/text-hates-you/
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.
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 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 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.
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...
Exactly which release of Windows do you think didn't supply a terminal?
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.
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.
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 feel like there was a larger discussion too, but can't find it. Anyone?
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.
Here's an interesting article: https://danluu.com/input-lag/
EDIT: you can download built packages from the Releases tab https://github.com/microsoft/terminal/releases
It is a testament just how much behind times MS was up until recently.
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?
30 seconds or so
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
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.
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.
https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo...
You typically need special hardware to measure it, or find review sites that go out of their way to cover it.
It was extremely barebones six months ago but it's come a long way, and faster than anything else I've tried.
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.
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.
Windows 7 (without SP1) is already unsupported.
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.
If anyone is interested in that sort of thing, a while back I put together a very detailed post on picking a good monitor for software development at: https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo...
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.
> 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.
I would say that combined with DPI scaling, his port provides a reasonable rule of thumb.
I very much doubt the console is watching vsync either.
