Without meaning any snark at all, why does this matter? I have used Terminator for approximately a thousand years and never thought it needed to be faster? Am I missing out on something?
Without meaning any snark at all, why does this matter? I have used Terminator for approximately a thousand years and never thought it needed to be faster? Am I missing out on something?
In general, I'd agree. Using xterm/urxvt/alacritty, even kitty, there's no issue whatsoever. I don't see an issue with speeding them up, but it's not worth too much effort. That calculus is why...
In general, I'd agree. Using xterm/urxvt/alacritty, even kitty, there's no issue whatsoever. I don't see an issue with speeding them up, but it's not worth too much effort. That calculus is why the tech has stagnated for so long.
On the other hand, VTE-based terminals like Terminator are genuinely slow and resource-intensive enough to annoy me. Totally noticeable lagtime between input being sent and programs receiving it, real slowdowns in the context of printing a lot of data to the screen (such as when cating something or updating the system with verbose flags), it is a bottleneck. But that's really all, annoyance. It's almost never going to meaningfully slow down task completion, but every 200 ms wait that should have been done within 50 gets grating to watch.
I always appreciate optimizing for low input latency and high responsiveness at all times. It's why I prefer mosh over ssh. Laggy interfaces is my biggest frustration with software, considering...
I always appreciate optimizing for low input latency and high responsiveness at all times. It's why I prefer mosh over ssh. Laggy interfaces is my biggest frustration with software, considering how powerful our processors have become.
On the other hand, adding GPU rendering complexity so you can draw every line of (unreadable) text at 60+ FPS when you cat a massive file inadvertently... is something I don't need, personally speaking.
I've never gone digging into terminal emulator code, but I don't think it's necessary to do the latter to achieve the former.
Instead of making terminal emulators faster (when they're already plenty fast enough as-is) I wish more people were putting effort into not emulating old terminals at all. We have countless...
Instead of making terminal emulators faster (when they're already plenty fast enough as-is) I wish more people were putting effort into not emulating old terminals at all. We have countless software for emulating ancient hardware, and I get that having these things around for compatibility with old programs is good, but why are we still limiting ourselves to all this cruft. I'd be very interested to see some real attempts at creating a new standard for command-line interfaces.
That's really an interesting take, but I wonder if you ever use the Linux command line for what you do? Those programs don't feel "antiquated" or "limiting". They are better than most GUI at that...
That's really an interesting take, but I wonder if you ever use the Linux command line for what you do? Those programs don't feel "antiquated" or "limiting". They are better than most GUI at that they do. They still get updated and work really well.
A command line interface and a terminal emulator are not the same thing. Command line interfaces are great for complex tasks. But there's no need to emulate the protocol of a 1960s terminal, and...
A command line interface and a terminal emulator are not the same thing.
Command line interfaces are great for complex tasks. But there's no need to emulate the protocol of a 1960s terminal, and take on all the baggage that brings, in order to make a command line interface.
I daily drive Linux, and I agree there are plenty of cool and interesting and well put together tools designed for usage in terminal emulators, but a lot of these tools are also very simple and...
I daily drive Linux, and I agree there are plenty of cool and interesting and well put together tools designed for usage in terminal emulators, but a lot of these tools are also very simple and don't necessarily rely on anything specifically unique or special about terminal emulators, most of them just output plain text, maybe with escape sequences to color things. In general I think escape sequences suck to work with and terminals are also very weird about handling input.
I don't think anything about how terminal emulators work is actively beneficial beyond compatibility, inventing a new standard wouldn't have to mean losing capability but rather going about those capabilities in new ways that aren't as limiting or awkward for developers while also introducing the potential for new capabilities. I won't claim to know what that should look like, but I hope somebody smarter than me figures that out and makes it real.
Michael Larabel "Just going to put it out there because I don't intend to do anything with it, but I have created a terminal emulator that is twice as fast as the closest GPU-based renderer I've...
Michael Larabel
"Just going to put it out there because I don't intend to do anything with it, but I have created a terminal emulator that is twice as fast as the closest GPU-based renderer I've found (at least on Linux) which was Alacritty."
Hergert, who is known for his work on GNOME Builder and Sysprof and other GNOME contributions through his employment at Red Hat, tweeted on Friday
He added part of the reason he was able to make it so far was due to his knowledge from writing a large part of the GTK renderer code and the profiler to guide how to spend the time optimizing the code. And also adding:
"Instead of continuing Termkit though, I just made a bunch of VTE patches because it's good enough. Console includes those patches here...And yes it updates at frame rate without dropping frames because it only processes what is visible when rendering the next frame. I also found it interesting how the field of contenders all use multiple threads and some even attempt to balance between CPU and scroll performance. Termkit used a single thread, and did both with less resources."
As for not developing it further, Hergert tweeted:
"I don't care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one."
Without meaning any snark at all, why does this matter? I have used Terminator for approximately a thousand years and never thought it needed to be faster? Am I missing out on something?
In general, I'd agree. Using xterm/urxvt/alacritty, even kitty, there's no issue whatsoever. I don't see an issue with speeding them up, but it's not worth too much effort. That calculus is why the tech has stagnated for so long.
On the other hand, VTE-based terminals like Terminator are genuinely slow and resource-intensive enough to annoy me. Totally noticeable lagtime between input being sent and programs receiving it, real slowdowns in the context of printing a lot of data to the screen (such as when
cating something or updating the system with verbose flags), it is a bottleneck. But that's really all, annoyance. It's almost never going to meaningfully slow down task completion, but every 200 ms wait that should have been done within 50 gets grating to watch.I always appreciate optimizing for low input latency and high responsiveness at all times. It's why I prefer mosh over ssh. Laggy interfaces is my biggest frustration with software, considering how powerful our processors have become.
On the other hand, adding GPU rendering complexity so you can draw every line of (unreadable) text at 60+ FPS when you cat a massive file inadvertently... is something I don't need, personally speaking.
I've never gone digging into terminal emulator code, but I don't think it's necessary to do the latter to achieve the former.
Cool Retro Term is one such GPU-driven terminal. It is indeed quite snappy.
Instead of making terminal emulators faster (when they're already plenty fast enough as-is) I wish more people were putting effort into not emulating old terminals at all. We have countless software for emulating ancient hardware, and I get that having these things around for compatibility with old programs is good, but why are we still limiting ourselves to all this cruft. I'd be very interested to see some real attempts at creating a new standard for command-line interfaces.
That's really an interesting take, but I wonder if you ever use the Linux command line for what you do? Those programs don't feel "antiquated" or "limiting". They are better than most GUI at that they do. They still get updated and work really well.
A command line interface and a terminal emulator are not the same thing.
Command line interfaces are great for complex tasks. But there's no need to emulate the protocol of a 1960s terminal, and take on all the baggage that brings, in order to make a command line interface.
I daily drive Linux, and I agree there are plenty of cool and interesting and well put together tools designed for usage in terminal emulators, but a lot of these tools are also very simple and don't necessarily rely on anything specifically unique or special about terminal emulators, most of them just output plain text, maybe with escape sequences to color things. In general I think escape sequences suck to work with and terminals are also very weird about handling input.
I don't think anything about how terminal emulators work is actively beneficial beyond compatibility, inventing a new standard wouldn't have to mean losing capability but rather going about those capabilities in new ways that aren't as limiting or awkward for developers while also introducing the potential for new capabilities. I won't claim to know what that should look like, but I hope somebody smarter than me figures that out and makes it real.
Michael Larabel
"Just going to put it out there because I don't intend to do anything with it, but I have created a terminal emulator that is twice as fast as the closest GPU-based renderer I've found (at least on Linux) which was Alacritty."
hmmm
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1411137-linux-terminal-emulators-have-the-potential-of-being-much-faster?p=1411164#post1411164
One of the reasons I have switched to Kitty. That and the images. It's awesome to be able to output from gnuplot to terminal directly.
I use foot and love it. Highly recommend.
I lol'd... Gnome always felt so bloaty to me, though that's a bit excessive.