3 ms·

Would there be a more canonical way do do this?

• nine_k 2y ago
  Back in the day (around 1990) I implemented a gif-like effect for terminals, which happened to be old monochrome hardware terminals on slow (9600?) RS-232 ports, attached to a venerable PDP-11. It took several text files with ASCII "pictures" (character data only, no control codes, 80x24) as animation frames, and calculated simple per-line "diffs". Then it generated a sequence of cursor movements to only update the affected areas, skipping large parts of the picture. That made it much faster than the naive overwriting the whole screenfuls from top, with a visible delay between parts of the screen. My version was able to run "simultaneous" small animations quickly at distant parts of the screen, because they took very few bytes to navigate to and update. * *. * o/ -/M _H_ E.g. a "juggler" like this could juggle quickly, inside a mostly stationary "circus", with "flags" waving high above on top of it. With current terminals giving you 60fps in true-color mode, it makes little sense, of course.
• deathanatos 2y ago
  Not redrawing the parts of the screen that don't need to be redrawn. There's going to be a tradeoff between the amount of works the terminal has to do parsing the input stream, the amount of work the terminal has to do to redraw/update its own buffer, and the amount of work necessary in the program to compute the necessary move commands. IIRC, ncurses does this under the hood.
  • vanderZwan 2y ago
    To be fair, the effects shown here update such a significant part of the screen that tracking the diffs might be bigger overhead than a full-screen refresh
• m463 2y ago
  I think the canonical way would be to ship this in some sort of hard-to-uninstall snap or flatpack package.
  • cl3misch 2y ago
    Flatpak is actually pretty nice and not affiliated with Canonical. No forced automatic updates with a daemon and easy to manage.