4 ms·

Well since GPU acceleration minimizes latency (because of zero-copy, all character textures are resident in video memory), that is a boon to perceived responsiv

Well since GPU acceleration minimizes latency (because of zero-copy, all character textures are resident in video memory), that is a boon to perceived responsiveness. IMO that is the single most important feature in a terminal, next to correctness. It’s like typing on an old serial terminal.

geokon 5y ago
Latency and throughput benchmarks don't confirm this. Eshell has one of the best latencies (that's why it feels so responsive compared to VS Code) but low throughput Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. GPU terminals seem to do this kinda slowly last I checked
- gravypod 5y ago
  > Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) Why? Many commands I've run have produced a lot of log output in my day.
  - geokon 5y ago
    Bc you wanna see the output? With less you can go page by page and read the output. If there is so much output you can't read it.. then what's the point of printing it to the screen? If you're looking for something in the stream then maybe you should grep for it? I'm not saying you never ever should barf to screen - but as far as I can see, you kinda have to strain yourself to concoct a "valid" usecase
    - vidarh 5y ago
      The irony of this is that with a faster terminal you'll be even less likely to actually read the data scrolling by. And the solution is very simple: Update a text buffer in one thread and render updates as fast as possible on another. If something barfs massive amounts of text you won't ever see all of it as not all of it will get rendered as it'll have "scrolled past" before the renderer gets to it. But it won't matter because it will be in scrollback if configured and you'd never have been able to read it as it passes by anyway, even with much faster rendering.
- CyberRabbi 5y ago
  > And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. No textures need to be updated. The texture stays in VRAM across each frame, just need to change which texture the character cell points to. That is zero-copy. If you were to do this with a software rendered terminal, at minimum the software would tell the windowing system which region of the window changed and then copy that region to VRAM. That’s only if the window system supports region updates, if not you’d need to copy the entire window to VRAM each frame. Much slower than just twiddling a pointer to a texture.
  - geokon 5y ago
    Show me the numbers.. https://danluu.com/term-latency/ https://danluu.com/term-latency/
    - CyberRabbi 5y ago
      Well all these data tell us is that alacritty has more latency than some terminals and less latency than others. It does not tell us why it displays the latency that it does. In other words, correlation is not causation. Many other factors are at play here. I’ve given you a rationale for why the GPU rendering technique inherently minimizes latency over the software rendered technique. Can you provide a rationale for why software rendered terminals would have an inherent advantage in terms of latency?

geokon 5y ago

Latency and throughput benchmarks don't confirm this. Eshell has one of the best latencies (that's why it feels so responsive compared to VS Code) but low throughput Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. GPU terminals seem to do this kinda slowly last I checked

gravypod 5y ago
> Generally if you are barfing meg's of data to screen you're prolly doing something wrong... (You prolly wanna be using less?) Why? Many commands I've run have produced a lot of log output in my day.
- geokon 5y ago
  Bc you wanna see the output? With less you can go page by page and read the output. If there is so much output you can't read it.. then what's the point of printing it to the screen? If you're looking for something in the stream then maybe you should grep for it? I'm not saying you never ever should barf to screen - but as far as I can see, you kinda have to strain yourself to concoct a "valid" usecase
  - vidarh 5y ago
    The irony of this is that with a faster terminal you'll be even less likely to actually read the data scrolling by. And the solution is very simple: Update a text buffer in one thread and render updates as fast as possible on another. If something barfs massive amounts of text you won't ever see all of it as not all of it will get rendered as it'll have "scrolled past" before the renderer gets to it. But it won't matter because it will be in scrollback if configured and you'd never have been able to read it as it passes by anyway, even with much faster rendering.
CyberRabbi 5y ago
> And of course your next keystroke is not zero copy. It needs to be sent to the GPU and the texture needs to be updated. No textures need to be updated. The texture stays in VRAM across each frame, just need to change which texture the character cell points to. That is zero-copy. If you were to do this with a software rendered terminal, at minimum the software would tell the windowing system which region of the window changed and then copy that region to VRAM. That’s only if the window system supports region updates, if not you’d need to copy the entire window to VRAM each frame. Much slower than just twiddling a pointer to a texture.
- geokon 5y ago
  Show me the numbers.. https://danluu.com/term-latency/ https://danluu.com/term-latency/
  - CyberRabbi 5y ago
    Well all these data tell us is that alacritty has more latency than some terminals and less latency than others. It does not tell us why it displays the latency that it does. In other words, correlation is not causation. Many other factors are at play here. I’ve given you a rationale for why the GPU rendering technique inherently minimizes latency over the software rendered technique. Can you provide a rationale for why software rendered terminals would have an inherent advantage in terms of latency?