10 ms·

As far as I keep fingers crossed for your efforts, you will not achieve pure text console speed (or even be close to it), linux one the people can easily compa

by rdslw 9y ago

As far as I keep fingers crossed for your efforts, you will not achieve pure text console speed (or even be close to it), linux one the people can easily compare to iterm. There is a lot of reasons, mostly: font rendering, unicode handling, all effects, while pure text is simply copying memory areas and nothing more. full answer: https://unix.stackexchange.com/questions/41225/can-a-terminal-emulator-be-as-fast-as-tty-1-6/41227 https://unix.stackexchange.com/questions/41225/can-a-termina...

ajnin 9y ago
You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem. Maybe an opengl or similar renderer would alleviate the actual drawing of the glyphs on the screen.
- gnachman 9y ago
  A high quality GL renderer would be lovely. It would need to be very capable, and a lot of the time core text spends is on layout rather than rendering, but at least for the plain-ASCII case this would be a huge win. OTOH, it would always look a little off.
- JohnBooty 9y ago
  You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem Sorry, no. You're totally conflating two orthogonal concepts: throughput and latency. Rendering 60fps (or even 1,000fps) is not remotely the same as achieving low latency. Even if a game is rendering at 60fps, input latency (the time between a user clicking a button and something happening on the screen) is often over 100ms. This article breaks it down... there's a link to it in the original story about terminal latency posted by OP: http://renderingpipeline.com/2013/09/measuring-input-latency/ http://renderingpipeline.com/2013/09/measuring-input-latency...
  - MaulingMonkey 9y ago
    Some of the listed problems are throughput problems, not latency problems (both in this thread and the original article), so it's not a mistake to address both types of performance problems. And while throughput and latency might be orthogonal concepts, they're not nearly so orthogonal in practice when optimizing. Reducing e.g. an average 48ms frame time, or a 100+ms frame stall, will improve both throughput and worst case latency. There are a few optimizations which focus more exclusively on one or the other, but my experience is that they tend to be rarer. Your reply also reads like games are getting away with introducing 100s of milliseconds of additional latency, which just isn't the case for the most part. There is hardware and kernel buffering that userland software can do little about, admittedly, that can easily add up to getting you above 100ms as you say. Even there, some improvements can be made: Gsync reduces latency by getting rendered frames displayed as quickly as possible, by tying refresh rates to frame rates. "Time warp" reprojects rendered scenes shortly before refresh to help reduce latency between head movements and screen movements in VR - but this is also effectively "improving" throughput and worst case latency, by ensuring there's always a new head-rotated frame - even if the main scene renderer wasn't able to provide a full scene update yet. There's some talk of going back to single buffering and chasing the beam, although I'm skeptical if that'll actually happen for anything but the most niche applications.
JdeBP 9y ago
Nowadays, though, very few consoles actually use the display hardware in text mode. Moreover, text mode display hardware does not absolve one of Unicode handling.

by rdslw 9y ago

ajnin 9y ago

You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem. Maybe an opengl or similar renderer would alleviate the actual drawing of the glyphs on the screen.

gnachman 9y ago
A high quality GL renderer would be lovely. It would need to be very capable, and a lot of the time core text spends is on layout rather than rendering, but at least for the plain-ASCII case this would be a huge win. OTOH, it would always look a little off.
JohnBooty 9y ago
You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem Sorry, no. You're totally conflating two orthogonal concepts: throughput and latency. Rendering 60fps (or even 1,000fps) is not remotely the same as achieving low latency. Even if a game is rendering at 60fps, input latency (the time between a user clicking a button and something happening on the screen) is often over 100ms. This article breaks it down... there's a link to it in the original story about terminal latency posted by OP: http://renderingpipeline.com/2013/09/measuring-input-latency/ http://renderingpipeline.com/2013/09/measuring-input-latency...
- MaulingMonkey 9y ago
  Some of the listed problems are throughput problems, not latency problems (both in this thread and the original article), so it's not a mistake to address both types of performance problems. And while throughput and latency might be orthogonal concepts, they're not nearly so orthogonal in practice when optimizing. Reducing e.g. an average 48ms frame time, or a 100+ms frame stall, will improve both throughput and worst case latency. There are a few optimizations which focus more exclusively on one or the other, but my experience is that they tend to be rarer. Your reply also reads like games are getting away with introducing 100s of milliseconds of additional latency, which just isn't the case for the most part. There is hardware and kernel buffering that userland software can do little about, admittedly, that can easily add up to getting you above 100ms as you say. Even there, some improvements can be made: Gsync reduces latency by getting rendered frames displayed as quickly as possible, by tying refresh rates to frame rates. "Time warp" reprojects rendered scenes shortly before refresh to help reduce latency between head movements and screen movements in VR - but this is also effectively "improving" throughput and worst case latency, by ensuring there's always a new head-rotated frame - even if the main scene renderer wasn't able to provide a full scene update yet. There's some talk of going back to single buffering and chasing the beam, although I'm skeptical if that'll actually happen for anything but the most niche applications.

JdeBP 9y ago

Nowadays, though, very few consoles actually use the display hardware in text mode. Moreover, text mode display hardware does not absolve one of Unicode handling.