31–40 of 43 posts
Curiously not listed: xterm, which has close to the lowest latency of any open source TE. But who uses that anymore?
These days, I could probably switch to another terminal, as I'm in tmux quite often, which creates those compatibility issues itself, no matter what "backend" you're using.
Curiously not listed: xterm, which has close to the lowest latency of any open source TE. But who uses that anymore?
I do, mostly. I often ran in some terminal emulation issues with other terminals, especially when using older software. These days, I could probably switch to another terminal, as I'm in tmux quite often, which creates those compatibility issues itself, no matter what "backend" you're using.
Xterm really is a terminal emulator. Most other "modern" TEs are more like shitty xterm emulators.
semi related but anybody know how i fix the powershell latency on windows? it's literally unusable as a shell besides running scripts.
Are you using old PowerShell or the newer Open Source PowerShell 6/7? Try also running it from Terminal, the official modern terminal app from the store. It's much faster than bare cmd or PowerShell, IIRC it's because of conhost.
Earlier quoted context omitted.
I do, mostly. I often ran in some terminal emulation issues with other terminals, especially when using older software. These days, I could probably switch to another terminal, as I'm in tmux quite often, which creates those compatibility issues itself, no matter what "backend" you're using.
The developer of xterm actually maintains a battery of tests which exercise corner cases in the DEC VT protocol and ensure that xterm conforms in the manner that a real terminal would: https://invisible-island.net/vttest/vttest.html Xterm really is a terminal emulator. Most other "modern" TEs are more like shitty xterm emulators.
Earlier quoted context omitted.
No, but I can read at 300 baud iirc.
Nobody was using 300 baud in the 90's! Maybe that's why I was confused.
~2 msec (mouse) 8 msec (average time we wait for the input to be processed by the game) 16.6 (game simulation) 16.6 (rendering code) 16.6 (GPU is rendering the previous frame, current frame is cached) 16.6 (GPU rendering) 8 (average for missing the vsync) 16.6 (frame caching inside of the display) 16.6 (redrawing the frame) 5 (pixel switching) I'm not very familiar with graphics pipelines, but some stuff here seems w…
It can work this way--e.g. nvidia exposes an 'ultra low latency mode' in their driver that caps prerendered frames to zero--but typically for smoother animation and higher average fps gpus will have a queue of several frames that they're working on, and this is irrespective of how many render targets you have in your swapchain. Danluu's breakdown above is actually correct for the typical case.
---
Thought I'd clarify how this works since there's lots of confusion in this thread. In the early days you would directly write pixels to memory and they'd be picked up by a RAMDAC and beamed out to the screen. So if you wanted to invert the color of the bottom right pixel it would take at most two frames or 33ms of latency if you were running at 60fps double buffered: first you set your pixel in the back buffer, wait up to 16.66ms to finish drawing the current front buffer, flip buffers, wait 16.65ms for the electron gun to make its way down to the bottom right corner, and then finally draw the inverted pixel.
With modern gpu's, the situation is very similar to sending commands to a networked computer somewhere far away. You have a bit of two-way negotiation at the beginning to allocate gpu memory, upload textures/geometry/shaders, etc., and then you have a mostly one-way stream of commands. The gpu driver can queue these commands to an arbitrary depth, regardless of your vsync settings, double/triple buffering, etc, and is actually free to work on things out of order. You have to explicitly mark dependencies and a 'present' call isn't intrinsically tied to when that buffer will actually end up displayed on screen. So there's no actual upper bound on latency here; even at 360hz if the gpu is perpetually 10 frames behind the cpu, each frame only takes 2.77ms to simulate and 2.77ms to render but the overall input lag could still be ~30ms. (In practice though, drivers will typically only render 2-3 frames ahead.)
Earlier quoted context omitted.
Nobody was using 300 baud in the 90's! Maybe that's why I was confused.
modems in the 90s would still negotiate 300 baud connections depending on how good the phone connection was, which could depend on the weather. I think there also needs to be a full duplex loop from the terminal emulator to the unix host and back for the character to show up on the screen. And consider that the both the PC that the emulator was running on was a 90s PC, and the web server I think was a shared host at…
Terminal emulators are not CPU intensive applications. I ran one on an Apple II (8-bit, 1 mhz) and it could keep up with at least 2400 baud. If you were refreshing the screen with vi, I could see it being slow.
The bad news is the defaults on modern platforms are often very bad for latency. The good news is that it is possible to achieve good latency on most modern systems with a lot of attention to detail. With good hardware and good software it is even possible to e.g. run console emulators with lower latency than they would have on original hardware connected to a CRT. I just wrote a three part series detailing a lot of…
According to docs, there are extensions WGL_EXT_swap_control_tear/GLX_EXT_swap_control_tear [0], that cause late frames to tear instead of wait a full frame. They don't work on my machine (my Intel HD 4000 reports that it is supported and then silently fails), but this should be the ideal swap mechanism.
[0]: https://registry.khronos.org/OpenGL/extensions/EXT/GLX_EXT_s...