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.
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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
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
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.
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.
Anyone that has used a 120Hz+ display will immediately notice that everything feels more responsive even with simple things like moving your mouse and scrolling.
I also find the responsiveness noticeable when typing. You'll be able to tell that the text appears faster on the screen.
I wouldn't say it's a requirement. But it does make the user experience nicer.
Now if only someone made a 34” ultra wide with 120Hz+. In particular one with 5120 x 2160 resolution. Maybe in 2022 at the rate high hertz monitors are coming for non-gaming uses...
I agree. I'd rather hi-dpi 32"+ monitors first though. Hidpi displays are becoming standard on top-end laptops but on desktop you're almost out of luck.
It's wild that the only hidpi 32" monitor is ~$5000, and it was released a few years ago now.
What are you calling "hi-dpi"? There's a ton of 4k monitors in the 27" to 32" range, which are definitely higher DPI than typical. And for a lot less than $5000.
I'm typing this on a 4k, 32" monitor, which is 137.68 DPI, but
I also have a Dell XPS 15, which is 4K and 15", 293.72 DPI, and the difference in sharpness is astounding.
The other problem with hidpi scaling (200%) at 4k 32", is that everything is huge, and you lose a lot of screen real estate.
DPIs don't mean anything unless you factor in viewing distance.
In fact, it is common to recommend a vertical viewing angle of 30 degrees. Not more as it tends to increase eye fatigue and neck pain. If you follow that recommendation, what matters is the definition (the number of pixels), not the resolution in DPI.
So, let's run a few calculations. The "retina" resolution is based on a pixel size of 1 arc-minute, that's 20/20 vision, at 30 degrees, that's 1800 pixels. 4k is 2160 vertical, so that's about the limit of human vision. So, basically, 4k is what you want at any size.
8k is not useless but you are pushing the boundaries here. In order to notice it, you need perfect, over 20/20 vision, high luminosity and high contrast. Beyond 8k, you enter superhuman territory, with an exception: you can notice discontinuities at a much higher resolution (vernier resolution), but it only matters if you don't have anti-aliasing. And of course, high contrast, luminosity and perfect vision.
There are exception. For example there is a limit on how close a screen can be, so having 4k on a tiny smartphone screen is mostly useless. The other end of the spectrum would be VR, with fields of view over 100 degrees, 8k per eye is considered a minimum for an immersive experience.
>So, let's run a few calculations. The "retina" resolution is based on a pixel size of 1 arc-minute, that's 20/20 vision, at 30 degrees, that's 1800 pixels. 4k is 2160 vertical, so that's about the limit of human vision. So, basically, 4k is what you want at any size.
No, because I don't want to move my 32" monitor further away to get that 30 degree viewing angle. The reason I have a 32" monitor for work is to have more screen real estate. A 30 degree viewing angle works for watching movies and stuff, but when I use it for coding, I essentially have multiple 30 degree viewing (on-screen) windows.
You might say "ok well just get two or three monitors", but that isn't the same either. Besides the space between the monitors, with one large monitor I can subdivide my screen space in any way depending on what I'm doing, where each window has a 10-30 degree viewing angle or whatever.
>you can notice discontinuities at a much higher resolution (vernier resolution), but it only matters if you don't have anti-aliasing.
That's just not true though. It does matter even with antialiasing, the difference is clear. In particular, the dell xps 15 2019 has a ~290 dpi OLED, which has high contrast.
30 degrees vertical is actually a recommendation for work[1], not for movies. If you look around for guide about ergonomics, you will often see that 30 degrees figure, or "top of the screen at eye level, center 15 degrees down", which mean the same thing.
For movies, THX recommends a 36 degrees horizontal viewing angle[2], which is about 20 degrees vertical. Recommendations vary, sometimes it is 30 degrees, sometimes it is 40, but always horizontal.
Now, no one will force you. If you prefer to have a very large screen right up your nose, that's your choice, and maybe your work environment calls for it. But it is just not what it is generally recommended and I would put it into the "exception" category. And sure, in that case, increased resolution is good.
As for antialiasing, it will not make the image sharper, quite the opposite in fact. However, if your resolution is so that it is over your visual acuity (you can't distinguish between 2 thin parallel lines and 1 thicker line), antialiasing will take care of superaccuity. That's the ability of your brain to use image processing techniques to detect jaggies that are finer than what you eye can see. If you have good vision and a 4k monitor closer to you than the recommended distance, it is normal to see the difference even with anti-aliasing turned on.
If the recommended horizontal viewing angle for a movie is 36 degrees, why is it hard for you to understand wanting a desktop PC display with significantly larger field of view, given that large PC displays are used subdivided into multiple windows? There's real usability value for a PC display that extends further into your peripheral vision than a movie screen, because you don't actively watch the whole PC screen at once.
>DPIs don't mean anything unless you factor in viewing distance.
Between phone, table, and laptop, monitor, yes.
But when speaking of monitors alone, it's not that relevant an observation in practice, since most monitors, whether 27", or 32", or 24" are seen from more or less the same distance.
> 4k is 2160 vertical, so that's about the limit of human vision.
This is false. Misalignment of borders can be detected with a precision up to 10 times better than visual acuity [0], therefore your numbers should be multiplied by 10, meaning 40K is the optimal screen resolution, or 80K for people with particularly good vision.
Its conclusion is that with anti-aliasing, you only need half the resolution to reach the detection threshold for misalignment of borders compared to other visual acuity tests.
You could use bitmap fonts to get truly sharp text. I'm a big fan of terminus at 9pt. It makes non-bitmap fonts look blurry and awful by comparison.
A real shame that Pango broke bitmap support and your choice of terminal emulator and other stuff is limited now.
IMO this is a huge and underrated advantage of bitmapped fonts.
The problem is that you need a font at exactly the right scale to realize this advantage. The right scale is often different for every user/monitor pair and changing the scale means redrawing the font which is a ton of work.
To keep the same pixel density you'd need an 8K at 30" or 10K at 36". I'm sure we'll get there but not anytime soon, at least not at prices almost anyone would be willing to pay, or not without sacrificing other specs that you surely want.
That's not true at all. Fonts & other vector-based graphics scale to any resolution just fine.
The myth of 1x, 2x, and 3x being "preferred" is just an Apple-ism because their UI toolkit is pixel-based. That's a flaw in their toolkit, not an inherent technical constraint. Combined with then Apple scaling it yet again after it's rendered.
>The myth of 1x, 2x, and 3x being "preferred" is just an Apple-ism because their UI toolkit is pixel-based. That's a flaw in their toolkit, not an inherent technical constraint. Combined with then Apple scaling it yet again after it's rendered.
Apple-ism? Please. Most plarforms and GUI libs are pixel based, and we always have photos to see and other such bitmap assets.
Your photos rarely if ever match the size they are displayed at anyway. What Apple does is the worst possible thing for your photos, which typically end up double resized (once to the app's internal size, then once again for the display scaling).
The largest platform, Android, is not pixel based. The largest desktop platform, Windows, also went through the effort to try and do things properly here, letting the app handle DPI instead and then providing updated toolkits to do that automatically.
You are not getting any 'sharpness benefit' if your 4k display is showing an upscaled 1080p image.
All applications i use on windows support scaling natively, and provide crisp text at 150%. It's not 2010 any more, this is a solved problem. Anything that doesnt should be killed with fire.
I have the same displays as you- Dell 4k @ 15" and currently using a 32" 4k (I sit 2ft away from it). I also have a Macbook Pro 16 (3072×1920). I honestly don't see a substantial difference between any of them, and I'm generally pretty picky about resolution.
I use 4K 32" with scaling at 100% and it seems totally fine. Lots of real 15-17" laptop screen at 4K makes no sense to me as I can't use 100% as the text size becomes too small.
What I have already feels crisp enough and since I do a lot of programming I'd rather see more lines of code than increase scaling for no real benefits. As a matter of fact one of the 2 4K monitors on my desk is in portrait mode just for that.
This is the argument that HiDPI displays are pointless if you're not very close to the monitor, and if you've used a retina display, you know that there is absolutely a difference.
You probably hold your phone about 30-40cm from your face. You probably look at your laptop screen at 50-60. You should be at least 75cm it not 90 or 100cm away from a big monitor.
It's that you have to go to such a larger screen size. I just upgraded my monitor from a 1080p. I really wanted a 24" @ 4k for higher dpi and crispness. Practically impossible to find, despite being common on laptops with much smaller screens. I had to go up to 27" instead, which is still crisp, though not as much, and larger than I wanted for the space it's in.
There was some really dark times around 2002 to 2012 where good CRTs became unavailable and almost every LCD screen was "HD" meaning 1080p. Still at the tail end of these times, I guess.
They were. Most tech people I knew had a 19 or 20 inch monitor, at 1600x1200 in the late 90s/early 2000s. 2048x1536 was available too. Early LCDs were usually 1280x1024 and by around 2005, larger sizes and 1080p LCDs were available. It was hard to find anything approaching the pixel density of an old, common CRT until around 2010 if I recall correctly.
I currently use multiple monitors, and apparently nobody at Apple HQ uses a monitor in portrait mode. Catalina routinely forgets the monitor is portrait and requires manually changing it back _every time the machine is locked_.
Why is this relevant? I'm seriously considering a 1440p 32:9 240hz Samsung G9 so that I can ditch multiple monitors and move to a single display with similar overall screen space just to dodge pesky multi-screen bugs like this. Just docking my laptop and using a massive screen would be SO NICE!
Only thing that's holding me back is I really want 2160p tall in that form factor. Will probably need to wait for DisplayPort2.0
I personally can't stand the ultrawides. OS support for a huge monitor just isn't where I'd want it to be. Sure I can install applications to handle window management better and whatnot, but even trivial things like fullscreen video don't work well at all.
I'm looking for something similar, but not ultrawide. There's plenty of 27" 4k 100Hz+ monitors, but not the same in 30-36" sizes. I have 3x 24" monitors, and would like to replace one or two of them with one bigger screen that's higher resolution and faster.
Yeah I'm on an iMac Pro (which is the same display as the 27" iMacs) as my main display at its pretty glorious with 218 PPI. My older 34" ultra wide next to it is really showing its age, both in terms of overall quality and 110 PPI. The newer LG 34" that is 5K2K is not horrible at 164 psi.
If Apple just sold there 27" display for 1500 bucks or something they would make a killing for folks who want a really nice pro display but don't need the overkill of the Pro Display XDR.
My current dream monitor is a 42inch 3840x2400 or 7680x4800 - 120hz screen.
I love the 16:10 aspect ratio and real estate of a monitor like that. I’m currently running 3 24inch monitors in portrait mode, so 3600x1920
I am still mad that all display vendors went 16:9. The black bars are fine when watching movies if you mostly use the display for productive work, whereas 4:3->16:9 was a shitty transition for someone like me working mostly with text and written music. It was as if the world had decided that the use case for computer screens was something else than what I was using them for. Although I do costume some video content on my computer today, I would switch to a high-res 4:3 display instantly.
A 27" 4000x3000 display would be a dream come true.
I'm waiting for the same thing. Hoping LG actually has this in the works, as their current 34" 5120 x 2160 has been out of stock for a while now, and they make a bunch of other high refresh rate displays.
The LG 38GN950-B [0] gets close. 3840x1600 so not quite your wanted resolution but close - enough to fit most 4K movies if you remove the black bars. Personally I am hoping someone will make an OLED with this format.
I doubt you'll find any gaming monitors at that resolution for a while. The newest Nvidia GPUs can't hit high enough frame rates at 4k to utilize 120Hz.
1. With DLSS 2.0 you can get 120+ fps in a lot of things on the 3080 @ 4k
2. No one need do anything except die, but shaving a few ms of response time is nice for productivity. No one thing is critical but making sure you have a keyboard, mouse, monitor, refresh rate, and programs that aren't throwing latency out the window makes for an overall nice feeling system.
My understanding is that if you aren't gaming (i.e. most of the content on your screen is static) your GPU is smart enough not to redraw the entire frame so you can probably get very low latency refreshes.
Even without DLSS, this isn’t necessarily true. My 3080 has no problems pegging some recent games at 144-160 fps at the corresponding refresh rate. In fact, I’m generally CPU bottlenecked at 1440p or below.
I bought a 165Hz gsync screen years ago for gaming.
I bought all of my other high-refresh screens because wow computing feels so much better in the day-to-day desktop because of it! Not joking in the least.
I can understand if you need the pixels and bit depth for color work. I just work with sRGB, and the panel I have is fine for that. I really do like the speed, though.
But the text isn't making it from your keyboard through the machine and to the monitor any faster. Seems like at 120hz you're just maybe going to catch it a frame earlier when it shows up.
It is, because there may be multiple things synchronizing their inputs and outputs to the refresh, which causes the refresh-related latency to be a number of frames. E.g. in some Linux compositors inputs are latched with the refresh, apps themselves may render in sync, and the compositor also draws in sync; the GPU driver would also introduce at least a frame of latency typically.
Another factor is that some (many?) 60 Hz displays buffer a whole frame themselves, and often don't have quick response times. If you go from a 10 ms response time IPS screen with a frame buffer to a 120 Hz gaming screen with 2-3 ms response time, you already got a difference of about 25 ms just in the screen itself.
8 ms is hard to notice. 50 ms less so.
The difference is pretty huge, even on systems that are much better tuned than Linux desktops (e.g. Windows 10).
That being said, while it is very nice and feels nice, it's not necessary for development work; I spend most of my days developing on a system over a VNC connection through a VPN, so the basic input lag of that setup is around 200-300 ms. Gnarly yes, but not particularly bad for text input. You get used to just do everything very slowly with the mouse.
If you want the lowest latency in a terminal, use a vga textmode console with a ps/2 keyboard. That's pretty hard to get on windows 10, so I'd go with Linux.
In the article:
> We get a 90 ms improvement from going from 24 Hz to 165 Hz.
As per the linked article, the observed delay improvement isn't one frame, more like ~3 frames. It doesn't go up from 1/24 to 1/165, it goes from 2.5/24 to 2.5/165.
Computer software waits a lot more than it did in 1977. That's why 240hz displays feel much more snappier even if it's supposed to be less noticeable -- you're waiting for same 3 frames, but they pass by much faster.
> A major source of latency is key travel time. It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin. ... Note that, unlike the other measurement I was able to find online, this measurement was from the start of the keypress instead of the switch activation.
That's disappointing. He isn't measuring latency nearly as much as he's measuring point of actuation.
With a clicky switch I expect it to actuate when I hear it. With a tactile switch I expect it to actuate when I feel it. With a linear switch it depends on the switch. You can get linear switches that actuate as soon as you'd like.
The more I think about this the more useless it seems. Several of the keyboards he tested come with your choice of switch, different switches with different actuation points, and so you can't just say Keyboard X has a latency of Y without mentioning what switch you were using if you're going to measure from the beginning of the keypress.
And on the other side: I very much notice the difference between a corded mouse and a Bluetooth mouse (not a cheap one). It's not unusable, but frustrating enough that I prefer the corded ones. And I'm not a gamer, just doing office stuff, browsing and programming.
I have tried like 5 Bluetooth mice, since BL4.0 the latency has improved from 'terrible' to 'tolerable'. It might be something to do with the windows bluetooth stack, as i noticed the respobce was more sluggish during high CPU use, while USB mice seem unaffected.
The same logitech mouse performs much faster through their universal wireless adapter than trhough bluetooth (it has 2 modes), they also have lightspeed adapter, but I haven't noticed much difference.
If you haven't already, get a high refresh rate monitor and a 1000 reports/sec "gaming" mouse. The Razer Viper Mini is light, which adds to the feeling of responsiveness. I've bought a couple for other people and they love them.
I recently got a 165 Hz monitor for my decade-old PC (Sandy Bridge era) and with my (now old) G302 mouse, it's like having a new, much faster PC.
Maybe there is something there about IDE hints and whatnot too rendering faster, but those are usually bottlenecked by some async background work (language servers, linters, etc.) anyway which would negate the benefit of the screen refresh rate being faster
This is also can be enhanced by tweaking up your mouse sample rates and whatnot. I used to do a lot of setting PS/2 mouse sample rates at 80Hz or more in late 90s that made Windows machines feel almost as nice to use as a Mac.
> The interface has two main signal lines, Data and Clock. ... To transmit a byte, the device simply outputs a serial frame of data (including 8 bits of data and a parity bit) on the Data line serially as it toggles the Clock line once for each bit.
Increasing the clock rate absolutely does reduce latency on a PS/2 port.
Yeah, this is my favorite gimmick of my Samsung Galaxy S20. 120Hz display+240Hz touch sensor makes everything feels so fast and responsive, this is the first Android device that feels faster than my iPad.
It's quite common for the touch panel to run at 2x the display refresh rate. Eg, 120hz touch panels have been quite common for years on phones despite the 60hz disply.
It helps both slightly with latency directly, but it also gives you more points to sample from for input prediction which then helps with latency even more. Or for things like drawing applications it'll give you smoother curves assuming the drawing app looks at all intermediate touch samples.
Some recent PC/laptop displays can do 100hz and I even feel a difference between that and the long-standard 60hz. It's a small effect but it's noticeable and it looks a bit smoother and better.
You may not notice, that doesn't mean nobody does. Also it can depend on your operating system. Windows 10 (maybe everything now?) forces you to be in vsync, so increasing refresh rate has a non trivial improvement on the # of ms for a keypress response.
Now whether you will notice that can depend what environment you are in. If your editor already has an input latency of 100ms then shaving 8 off probably is not noticeable. But going from 20 to 12 might be.
you can just point a phone camera at the keyboard and screen, record a video clip, blow it up into stills with ffmpeg, and then count frames
Even at 60fps, you should be able to see the difference between 30ms and 100ms. Newer phone cameras often have a "slow motion" mode that'll give you 120+ fps video, too
SOME people can see the difference between 30ms and 100ms, but it's almost impossible to actually see it. You'll mostly end up feeling that everything sucks and not knowing how or why.
the rate of persistence of the human eye is around 25Hz, hence PAL and NTSC framerates. the upper bound for those hypersensitive is around 50Hz, hence the later generation monitors. anything above this is nothing more than marketing hype. it seeming smoother is merely a placebo to justify the extra cost
"The human eye can't tell the difference past 30 FPS" was literally just a thought-killing cliche repeated by console gamers getting into internet slapfights with PC gamers.
While the difference is noticeable in that 30 vs 60 Hz example, high-contrast foreground/background scrolling is an even starker example: https://www.testufo.com/framerates-text. Just be warned high contrast examples like that can have confounding factors on some displays due to ghosting.
Corridor Crew did a fun and interesting video[1] on how good the eye is.
In it, they have a segment on frame rate[2], where he mentions that the neurons can only fire about every 13ms, or about 75 FPS. But, the important point, they're not in sync like a computer screen is. This means the effective update rate for a group of neurons can be much less.
This is not correct. Let's not dispute and go with your claim of 25Hz.
Even then, the problem is that eyes don't work like cameras or monitors. Our eyes don't work with "frames". Each receptor updates on its own time. It's easy to see that, if the updates are staggered, multiple sensors could perceive higher frame-rates, even if they can't individually.
However, there's another angle to this. Disregarding input lag, which is a very real phenomenon and is greatly shortened by higher refresh, higher refresh rate monitors are able to show more 'discrete' steps for anything that's in motion. Our eyes (and brains) perceive this as movement 'smoothness', even if they can't quite make out every single frame that's displayed.
This is very incorrect. With video, every person can tell the difference between 30hz and 60hz, if they at least know what to look for.
The easiest way to show this is by wiggling your mouse around quickly on a computer screen.
At 30hz - you'll see the mouse teleporting around - hopping from spot to spot, but not moving. For example, if you stare in the middle, and jerk the mouse quickly to the right, you'll see the 4 or 5 spots where it rendered.
With 60hz, you'll see the 9 or 10 spots - and have a stronger illusion of movement.
With 120hz, it might even look as smooth as a real object flying across your screen.
I'm wondering if this is why I find 120hz so jarring. It's almost as if I can't perceive the 'hopping' consciously, but I can subconsciously. It feels like my brain is asking "Wait, how did you get over there?" where "over there" is a fraction of a millimeter. I think maybe there is an uncanny valley for motion.
So does it seem smoother or does it not? I definitely notice the difference with 60fps video and 120Hz+ monitors.
Additionally, another thing I've noticed in the last decade is the very badly PWM-frequency-tuned LED headlights on some cars. Those engineers selected the wrong LED brightness and tuned it to terrible frequencies which leave flicker-trails when you look at or away from them.
Get those PWM frequencies above 500Hz please! Especially get above 200Hz with your LED frequencies at the very least.
~25Hz is the _lower bound_ for video* to appear smooth, _as long as there is motion blur_. But user interfaces do not add motion blur to moving objects. A computer monitor at 25Hz would be horrendous to use.
Lower framerates are less noticeable in low light, which is another reason why films look acceptable.
*Talented animators/cartoonists can get away with lower framerates
I love the new Windows Terminal (wt.exe) but this is one area where they really messed up. The latency between a keypress and a character appearing on screen makes the whole thing feel like a cheap experience. I have no idea what's causing the latency.
I suspect there some very big fancy rendering pipeline occurring, because when I open Windows Terminal I get the nVidia overlay popup which normally only comes up when I launch games, indicating the terminal is using a GPU-based rendering engine. Which I'm sure confers some interesting benefits, but it's a heavy price to pay when, at the end of the day, it's just a terminal.
I believe they do made a post about how conhost(the actual backend when you run cmd.exe from start) have such lower input latency compared to other windows terminals.
The cmd need to do a lot of things (font rendering, layout whatever) without help of other services (It need to work even without them, see the recovery mode). So it effectively bypass a lot of interactions with other services a normal program need to do in order to put the text on screen. It is basically the tty? in Windows.
But that also means it need to sacrifice a lot of things because that aren't available in recovery mode. You get no fancy emoji supports or whateve feature you would expect in a modern terminal. And the text rendering looks very bad until recently the remake the conhost.
Modern game engines buffer 3 or 4 frames, sometimes 5. Not unusual to have 140ms latency on 60hz screen between clicking mouse1 and seeing the muzzle flash.
* deferred vs forward rendering (deferred adds latency)
* multithreaded vs singlethreaded
* vsync (double buffering)
It's far cry from simplified pure math people think of when they think of fps in games or refresh rate for office and typing. Software is very very lazy lately, and most of the time these issues are being fixed by throwing more hardware at it, not fixing the code.
> Software is very very lazy lately, and most of the time these issues are being fixed by throwing more hardware at it, not fixing the code.
Some things cannot be 'fixed'. It's always a trade-off. You can't expect to have all the fancy effects that rely on multiple frames and also low latency.
If there was a simple software fix, GPU manufacturers would be all over it and pushing it to all engines. It's in their interests to have the lowest latency possible to attract the more hard-core gamers (which then influence others).
Just look at all the industry cooperation that had to happen to implement adaptive sync. That goes all the way from game developers, engines, GPUs, monitors. Sure that sells more hardware(which brings other benefits), but a software-only approach would also allow companies to sell hardware, by virtue of their "optimized" drivers.
Games that are aiming more for a "cinematic narrative experience" might be perfectly fine with a few 33ms frames of latency, and a total input latency far exceeding 100ms. Competitive twitchy games will tend to be more aggressive. And VR games too, of course.
In principle, you can push GPU pipelines to very low latencies. Continually uploading input and other state asynchronously and rendering from the most recent snapshot (with some interpolation or extrapolation as needed for smoothing out temporal jitter) can get you down to total application-induced latencies below 10ms. Even less with architectures that decouple shading and projection.
Doing this requires leaving the traditional 'CPU figures out what needs to be drawn and submits a bunch of draw calls' model, though. The GPU needs to have everything it needs to determine what to draw on its own. If using the usual graphics pipeline, that would mean all frustum/occlusion culling and draw command generation happens on the GPU, and the CPU simply submits indirect calls that tell the GPU "go draw whatever is in this other buffer that you put together".
This is something I'm working on at the moment, and the one downside is that other games that don't try to clamp down on latency now cause a subtle but continuous mild frustration.
Yeah, I'm far from an expert on rendering and latency, but presumably game developers put a ton of effort into ensuring that the pixels are pushed with as little input latency as possible. This may not have been a priority for Microsoft in their terminal.
The first comment in this function (DxEngine::StartPaint), for example:
// If retro terminal effects are on, we must invalidate everything for them to draw correctly.
// Yes, this will further impact the performance of retro terminal effects.
// But we're talking about running the entire display pipeline through a shader for
// cosmetic effect, so performance isn't likely the top concern with this feature.
For games, consistent, smooth frame rates and vsync(no tearing) is more important than input lag so often times things will be buffered.
That said, the VR space has a much tighter tolerance on input lag and there's hardware based mitigations. Oculus has a lot of techniques such as "Asynchronous Spacewarp" which will calculate intermediate frames based on head movement(an input) and movement vectors storing the velocity of each pixel. They also have APIs to mark layers as head locked or free motion etc.
What’s the current state of alacritty? Does anyone use it as their main terminal application?
I tried it a few years ago but stopped using it for reasons I don’t exactly remember at this point, and I see that it’s still pre-1.0. Wondering what people think of it these days.
I've been using it as my only terminal for ~6mo on linux/x11, linux/wayland, and macOS. I picked it because it was fast, simple, and cross-platform. By those criteria I'm very happy with it, never experienced a bug or crash either.
With lockdown keeping me at home, and having to RDP to work over a VPN, I've gone quite far down the rabbit hole this year experimenting with low latency keyboards (1000Hz USB polling, configurable debounce times), gaming mice and high refresh rate monitors (125Hz+), all to try and make my remote experience feel more local.
The threshold for me (and most people I think) is about 110ms between key strike and something appearing on the screen before something feels non-local and disembodied... which is good because I found I could get down to ~40ms local response time on a decent windows box. My 2015 macbook is about ~120ms for the terminal app.
That leaves 70ms latency budget to play with which can accommodate the the RDP overhead (~50ms) and the network hop (~10ms for me).
This whole journey started with me wondering if I should pay a small fortune for a better network connection, before I realised that most of the latency was in my keyboard and monitor!
I even built a Arduino Leonardo gadget to measure the lag systematically and some pcap software to spot the RDP packets on the wire. The code's pretty shoddy but it does the trick! You can see it and an example result with RDP here:
Nice, I didn't think that but it makes sense that network hop isn't so slow now. I am surprised RDP to work isn't as slow as I feared, the shared server they give us is a different problem. :)
I have a project right now where I have to connect to a VPN, then remote-desktop to a "jumper PC" that's dual-homed via VNC to a segregated PC running Windows XP on a manufacturing tool we recently got out of mothball to backfill Covid supply chain gaps. On the plus side - the ancient version of Visual Studio on that tool is surprisingly snappy!
All my coworkers remote desktop into their workstations at the office from a laptop at home to do dev work. I can't do it. vscode remote development extension has been my savior when I need to code locally and then flip over to RDP to run the deployment from a specific environment (the office)
The dev desktops in the office are a controlled environment that can be locked down. We need that as we work in closely regulated industries handling potentially sensitive data.
At least until we arrange for everyone to have company provided dedicated work laptops which we can (mostly) lock down to the satisfaction of our clients and their auditors, but the switch to mostly remote working this year happened at roughly the same time as budgets were squeezed a bit (bet you can guess why!) so that hasn't happened across the board yet.
Allowing RDP from non-secured devices "for the time being" is iffy, but we are getting away with it due to the circumstances.
Our development environments have been azure VMs for ages.
Latency is not really an issue to be honest. I think ping is about 15ms which is much less than the lag in this article. Right now I'm using the horrible, 2012-era work laptop with just Chrome running and there are delays typing this comment into HN which is a super lean site as it is.
The main downsides are actually
* crap single-threaded performance (don't think Azure has VMs over 3ghz except maybe the highly expensive GPU ones)
* Slow IO
* Video and audio over RDP really doesn't work.. no hardware graphics accel either... reduced ability to work on multimedia, we had one webapp where WebGL wound up behaving differently which we didnt
Citrix has made a whole thing out of speeding up this scenario. It's a big part of why customers still use their software despite their other numerous failings.
This reminds me of graphing calculators in the late 90s when I was at school. I initially had a HP, but it took what felt like 500ms to respond when I pressed a key. I switched to a TI-83 and it was chalk and cheese - instant response; you could even write programs in assembly. There was a small cottage industry of traded programs for it.
HP's early graphing calculators definitely had very high latency. But they dealt with it properly, which PC's don't. An HP-48 series calculator will buffer dozens of keypresses, and handle them in-order as if the UI had been instantly responsive. So you don't actually have to wait for a menu or dialog box to be drawn to the screen—if you've learned the necessary input sequence to perform the task you want, you can enter it at full speed. The keyboards were also very high quality with great tactile feedback, so you didn't need visual feedback on the screen to know your key press had been registered.
I'd pile on that the programmability of the HPs was amazing compared to the TIs. The manual for my HP-48sx was a chonkyboi but man could I do so much with it. Once I figured out how to calculate pitch frequencies for equal temperament (just a mathematical series) I was using the BEEP function (IIRC) to have my calculator play music.
I'd describe hp and ti as laggy and slick, respectively. The 50g is what I used in university, but now I seldom touch it as the 86/89 are so much more pleasant to use.
Since the HP50g is running an emulator of the 48G, it inherits a lot of the UI lag. It also inherits most of the UI efficiency; in my experience, the keystrokes saved outweigh any remaining visual latency deficit relative to the TI-89. But that's contingent on learning how to use it well in the manner of becoming a power user of emacs, while the TI-89's UI paradigms and learning curve feel more like using Microsoft Office.
> Anything less than effective immediate feedback is unacceptable for interactive use.
I feel like you're ignoring the presence of tactile feedback, which is in fact effective on the device in question. Possibly because basically no other electronic gadgets in your life give reliable tactile feedback anymore, so you're used to visual feedback as the only indicator that your tactile input was registered.
I use mechanical keyboards. I also use vim. I'm familiar with the concepts you're on about.
I used the hp50g throughout university. I'm well acquainted with it and with typing faster and navigating menus faster than the screen can update.
Regardless, there's literal centimeters of distance between keyboard and CPU. There's no excuse for the calculator UI to lag noticeably relative to the keypresses.
I got the ti-89 out of sheer curiosity, mostly because it's 68k based. After using it just a little, it was obvious to me I wouldn't be suffering the 50g much anymore.
Modern software is such garbage. We could make slack feel as good as counterstrike WRT input latency if we really cared hard enough about the end user experience. Unfortunately, chasing shiny (laggy) technologies is way more popular and marketable.
Electron is the new Flash. Bloat and lag. Using it is understandable as a tactical choice when it's expensive to maintain separate native apps everywhere but man, Slack is a 25 billion dollar company - surely they can write some native apps?
Same deal or worse with Teams, the performance of which is goddamn execrable. My laptop is an awful 2012 thing but it shouldn't take 5 seconds to switch between chats.
I haven't used it with slack but it works just fine with discord. You don't get voice noise cancellation with ripcord but you don't need that if you use rtxvoice anyway.
Yes! Slack, Teams, Discord, Spotify. All of these are horrible. I hate to use them. Good thing is I only have to use one of them.
I wish there was more modern low latency software.
Please please please point me to instructions on how to build a low latency PC.
I crave some good old fashioned responsive computing, but moreover I want to fill my classroom with these devices and show a new generation that, to borrow a catchphrase from a far more noble cause, it gets better.
Regarding monitors, OLEDs have a much faster response compared to LCDs. See this [1] for an example. As of why keyboard scanning has become so abysmally slow, it's beyond me. You'd think that this would be a solved problem even for cheap wired keyboards.
Sure, they are less portable and difficult to manufacture/repair. But their combination of refresh rate (without blur), image quality, and color reproduction are still second to none.
Considering the price of an nVidia 3080, which is standard PC gaming equipment, there must be a market for high end screens for gamers.
Until relatively recently I'd have agreed but at this point I'd take a modern display over a CRT assuming we're talking about high end. Popular options in the high end are displays like the LG 48 CX or some of the "G-Sync Ultimate" monitors like the Predator x27. These kinds of displays start at prices higher than a 3080 though so you don't hear about the market as much since people usually expect to spend less on a monitor than a GPU and the 3080 is generally consider the top of most high end price ranges.
> But their combination of refresh rate (without blur), image quality, and color reproduction are still second to none.
Not true. A current generation OLED (which will do 120hz) is superior to a CRT.
Even still, on many of those a good LCD has long been better than a good CRT. Color accuracy, for example. CRTs required constant fiddling & calibration to stay good at that, whereas a quality factory calibrated LCD will be much better in an "out of the box" or typical usage. Not really sure what you're calling "image quality" but it's hard to imagine that going any way but solidly in a modern high-end LCDs camp, which are brighter, wider color gamuts, higher resolution, and higher pixel densities than CRTs ever had.
> there must be a market for high end screens for gamers.
There is, which is why we have high resolution, high refresh rate, and adaptive vsync IPS monitors a plenty now. They come in all sorts of shapes & sizes, in resolutions & dimensions CRTs could only dream about.
At least I know I'm not wearing nostalgia goggles when I remember my early days on my Windows 95, and how fast the input responses were. It definitely feels as if input latency has degraded.
I’ve recently upgraded from a gtx550ti (~10 y.o.) card to an RX 570 (3 y.o.), and even though I get way more performance, it introduced a noticeable inputlag in csgo.
It just doesnt feel right, and slowmo video capture confirms it.
It would be interesting to measure input latency on the new M1 Macs and add them to the table. It certainly feels like they’ve managed to claw a bit back.
...which is, like the rest of the DOS-based Windows from Windows/386 onwards, itself a sort of hypervisor architecture --- DOS applications effectively run in VMs thanks to V86 mode, giving native performance. The difference is very noticeable if you open something like MS-DOS EDIT on Win9x vs. NT 4/2K/XP --- the latter runs in an emulated environment and the latency is enormous.
The Windows setup is convoluted, awkward, and weird sounding compared to the native app. They are using it for a reason though: it’s much much more responsive than native Linux LibreOffice.
It's a bit weird, I guess, but it's hardly convoluted or awkward. I downloaded a pre-baked iso for the os, another one for the office, and in about 10 minutes had a working, tolerable writing environment.
One thing I haven't seen is how does the M1 fare in terms of input latency (e.g. in text editors, like in those old tests done with vim, sublime, intellij, etc: https://pavelfatin.com/typing-with-pleasure/).
> Although we don’t have enough data to really tell why the blackberry q10 is unusually quick for a non-Apple device, one plausible guess is that it’s helped by having actual buttons, which are easier to implement with low latency than a touchscreen.
The Blackberry q10 runs Blackberry OS 10, which is based on QNX, which has a realtime microkernel.
I'm surprised the Apple 2e's is so high, given the seemingly simplistic nature of the machine. I'm also surprised the TI-99/4A's isn't higher, given how complex it is - with its BASIC interpreter implemented on top of a virtual machine.
Probably just the nature of the sort of chips you could buy at the time and their scan rates and debounce circuitry. As time marches on we have added a lot of abstraction into the mix. One thing I used to do to make old DOS computers 'feel faster' was to turn up the keyboard rates in the BIOS.
TI's throughput certainly was slower. It's been a few decades, but I'm pretty sure it was possible to type faster than the interpreter could keep up. (As a point of reference, listing a program was unbearably slow on the TI, and unreadably fast on the //e.)
I suspect it's just that input processing is so cheap on those early architectures, that latency is really dominated by hardware constraints and not by CPU (however slow it might be). Certainly, on the //e, I'm pretty sure the input routine did little more than copy the character to the input buffer and the screen buffer and advance the cursor. The TI's probably was not much more complicated, despite being implemented in bytecode.
Your assumption is very optimistic for a number of people: a generation of security policy wanted everything routed through central monitoring points so you get home network -> vpn -> corporate data center -> remote server and back, all in the hope that the monitoring system would see malicious traffic (since attackers know how to use encryption & obfuscation, this is usually easily bypassed).
In the appendix they mention something interesting - that apples CPU performance advantage isn’t magic, but very careful planning and testing on the right things, namely the entire App Store’s contents. That’s a huge dataset of real world applications you can test your designs against.
This is interesting but perhaps shows that keyboard/screen latency isn't as important as it once was.
Just about every application on Apple 2e relied on keypresses being shown on the screen. Modern devices and operating systems are displaying 'windows', streaming 3d graphics etc. and running a myriad of other services at the same time.
Sure, the computer is doing a lot more. Apps are still responding to key presses or mouse clicks though. Fortnite, AutoCad or Excel: I press a button I want to see the effect. Increasing delay strictly reduces your ability to control the system via feedback.
Even in a mostly passive app like a video player, it sucks if the play/pause button has a long-delayed effect. The tendency is to press the button over and over and feel correctly that we have lost control of the app.
Maybe it's a self-fulfilling prophecy kind of thing, do we have high speed games today as we used to, e.g. [1]? If game developers assume shitty hardware and software, they won't make things that require better latency.
The link was to an OSP Tourney Q3A mod playing Clan Arena mode, which was released later and became popular even later with better hardware available (another competitive mod was CPMA). You are right on one thing though, default configuration was in 20s of fps on a typical machine of the time and was in fact unplayable, so people had to configure game graphics to simplify it a lot to get high enough framerate, it was basically doom-like looking graphics, no effects, no textures, no shadows, etc.
If a game was playable at 20s of fps, I don't think it deserves a title of low-latency gaming.
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.