4 ms·
But what's the use case for this? When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal? There is no way for the
by usrbinbash 5y ago
But what's the use case for this?
When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal?
There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
- nix23 5y ago> But what's the use case for this? telnet towel.blinkenlights.nl
- joseluis 5y agowell... come to the future: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
- usrbinbash 5y agoAnd what exactly is the use case for this? If I want to work with images, animations, etc. I use a GUI library. These in turn already use hardware accelerated rendering. And I already have powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side; the DESKTOP ENVIRONMENT.
- filmor 5y agoPlease be aware that all uppercase comes across as quite aggressive. Writing a lot of data to a terminal can happen accidentally or by having an application running that throws out a burst of log messages. In both cases, you'll want to have your terminal to be responsive again as soon as possible and you want it to be light on your cpu s.t. it doesn't interrupt other applications.
- usrbinbash 5y ago> In both cases, you'll want to have your terminal to be responsive again as soon as possible. My terminal emulator doesn't become unresponsive just because the renderer cannot keep up. It still processes input, so if I accidentially cat some-linux-distro-1of4.iso ...I can still Ctrl-C it and stop the process. > it doesn't interrupt other applications. It can't do that anyway in an environment that does preemptive multitasking.
- southerntofu 5y ago> And what exactly is the use case for this? Terminal User Interfaces. There's technically no reason i can't check out an image in a folder when i'm browsing on an SSH session (yes i know i can rsync/scp && xdg-open but it's not exactly as fast to type as viu [0]. > powerful, optimized, tested, reliable software that enables me to work with terminal and GUI functionality side by side If you have tested and reliable desktop environments to recommend, i'm all ears. All the ones i've tried over the years have their own quirks and memory leaks (yes, that includes GNOME and KDE). But as you said, both approaches are complementary. I'm glad notcurses exists and works via graceful degradation, so people with a modern terminal can get the best while others can still get a featureful ncurses-like experience. [0] https://github.com/atanunq/viu https://github.com/atanunq/viu
- ohgodplsno 5y agoWhat about when you don't know that it ends up being megabytes ? Say you're running Gradle on a large project that does a full recompilation. You don't really particularly care, you know that module X has warnings, etc. But it still prints it all out by default. With carriage returns to update the current percentage, ANSI codes and more. Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. This is compounded by other factors, but ultimately, writing to the terminal is not an asynchronous thing, so your process _will_ be impacted by it being slow.
- usrbinbash 5y ago>Any millisecond that you spend blocking on outputting your terminal is time that your build can't take. Many Build tools don't just pipe the output of every program to their own STDOUT, but redirect them to a logger, which usually runs asyncronously, so from the PoV of the compiler, its output is processed without delay. Secondly, if I know that the build produces a huge amount of output, I redirect it to a file instead. If I don't know the first time, I interrupt, correct my command and re-build.
- wffurr 5y agoAndroid logs.