Linux Terminal Emulators Have The Potential Of Being Much Faster

Comments

• BatmanAoD@programming.dev ⁨1⁩ ⁨year⁩ ago

  “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.”

  wat

  source

  • astraeus@programming.dev ⁨1⁩ ⁨year⁩ ago

    Just write it in Rust, it will be faster than the C/C++ equivalent ^/s

    source
  • swordsmanluke@programming.dev ⁨1⁩ ⁨year⁩ ago

    I have literally written my own terminal. (In Rust, btw) It took me three years and four major rewrites. It’s way more than 20 loc.

    Also, I know way too much about ANSI escape codes now.

    source
  • onlinepersona@programming.dev ⁨1⁩ ⁨year⁩ ago

    This dude thinks he’s Rorschach

    They didn’t ask me to develop a terminal emulator, and I said no.

    source
• thingsiplay@kbin.social ⁨1⁩ ⁨year⁩ ago

  I used a number of terminals in the last decade and even 2 GPU accelerated ones, Kitty and Alacritty for about 2 years or so. Now I'm back on Konsole. I never saw a difference in their speed, because the terminal speed doesn't matter. Maybe there are edge cases, that's not something I discount. But for writing code or editing text files, or listing files with the shell, I never saw a difference or advancement for having a faster terminal.

  However, where they differ greatly is in their customization, feature set and what dependencies they have.

  source

  • Max_P@lemmy.max-p.me ⁨1⁩ ⁨year⁩ ago

    I found my terminal speed to not matter when most of what I do with it is over SSH administrating various boxes.

    Probably matters more for riced up vim users and TUI fans since you need a lot of responsiveness.

    source

    • thingsiplay@kbin.social ⁨1⁩ ⁨year⁩ ago

      I am a Vim user and TUI fan. It does not make any difference in my experience to use a fast GPU based terminal. Maybe something like st might startup faster, but that's it.

      source

      • -> View More Comments
  • GenderNeutralBro@lemmy.sdf.org ⁨1⁩ ⁨year⁩ ago

    Yeah. I’ve had issues on OS X in the past, since its Terminal is anything but optimized. I have occasionally had issues with extremely verbose programs where the lion’s share of execution time was actually spent displaying output in the terminal. Piping output to a file instead made execution lightning fast. This surprised me at the time because I figured it would be buffered and each process would run on its own CPU core.

    Not sure I’ve ever had this problem on Linux though.

    source
• autotldr@lemmings.world [bot] ⁨1⁩ ⁨year⁩ ago

  This is the best summary I could come up with:

  ---

  Prominent GNOME developer Christian Hergert announced he created a new terminal emulator that is twice as fast as the closest GPU-based renderer he’s found yet so far 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: “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.”

  And the obligatory screenshot of his experimental terminal emulator running a basic performance test alongside Alacritty:

  And also adding: "Instead of continuing Termkit though, I just made a bunch of VTE patches because it’s good enough.

  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.

  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.

  ---

  The original article contains 297 words, the summary contains 186 words. Saved 37%. I’m a bot and I’m open source!

  source
• o11c@programming.dev ⁨1⁩ ⁨year⁩ ago

  Speed is far from the only thing that matters in terminal emulators though. Correctness is critical.

  The only terminals in which I have any confidence of correctness are xterm and pangoterm. And I suppose technically the BEL-for-ST extension is incorrect even there, but we have to live with that and a workaround is available.

  A lot of terminal emulators end up hard-coding a handful of common sequences, and fail to correctly ignore sequences they don’t implement. And worse, many go on to implement sequences that cannot be correctly handled.

  One simple example that usually fails: \e!!F. More nasty, however, are the ones that ignore intermediaries and execute some unrelated command instead.

  I can’t be bothered to pick apart specific terminals anymore. Most don’t even know what an IR is.

  source

  • JaxNakamura@programming.dev ⁨1⁩ ⁨year⁩ ago

    Most don’t even know what an IR is.

    I’m glad I’m not a terminal emulator or I’d feel personally attacked.

    source
  • NostraDavid@programming.dev ⁨1⁩ ⁨year⁩ ago

    As someone who had to develop on a super-restricted, underpowered laptop: Speed meant a LOT to me. Being able to think faster than my laptop, because I was using vscode’s terminal (which is Electron based), was excruciatingly painful - Wezterm FTW! I used Alacritty, but due to windows versions pasting indented text made Alacritty indent more and more, which was a frustration for me. But I would agree that beyond a certain point speed won’t matter, because when your machine can be powerful enough to run vscode smoothly, that (Electron) won’t matter any more.

    Anyway, I fully agree with you; I just wanted to note that depending on the situation, speed may matter a LOT more than some may think :)

    source

    • o11c@programming.dev ⁨1⁩ ⁨year⁩ ago

      True, speed does matter somewhat. But even if xterm isn’t the ultimate in speed, it’s pretty good. Starts up instantly (the benefit of no extraneous libraries); the worst question is if it’s occasionally limited to the framerate for certain output patterns, and if there’s a clog you can always minimize it for a moment.

      source
• TootSweet@lemmy.world ⁨1⁩ ⁨year⁩ ago

  I use st exclusively on my personal machines. Konsole on my work machine (because KDE Neon is the only Linux distro the PC support department will deign to support.) I’d be very interested to see how st stands up against other terminals speed-wise.

  St feels very responsive compared to Konsole. Which maybe makes sense just because it has very few dependencies and that ultimately is oging to make for faster load times and less cpu cycles. Or maybe it doesn’t so much make sense because st focuses on a small codebase and few dependencies so maybe that means they’ll have less tricks like multithreading and hardware acceleration or whatever.

  But in general, when I have a choice, I almost always go for whatever solution has the fewest dependencies and it rarely steers me wrong. For instance, I used dwm for my window manager for a while, but I’ve switched to Sway mostly because I wanted to switch to a Wayland compositor.

  source

  • sip@programming.dev ⁨1⁩ ⁨year⁩ ago

    do you use arch, btw?

    source

    • TootSweet@lemmy.world ⁨1⁩ ⁨year⁩ ago

      Is it that obvious? 😉

      source

      • -> View More Comments
• robinm@programming.dev ⁨1⁩ ⁨year⁩ ago

  Just toebe sure, what’s the name of this new terminal emulator? termkit?

  source
• mvirts@lemmy.world ⁨1⁩ ⁨year⁩ ago

  We focused so much on if we could, we didn’t stop to think about it we should.

  How about instead of making my terminal faster, I just use tmux and skip most of the data I’m needlessly dumping to the terminal?

  source
• onlinepersona@programming.dev ⁨1⁩ ⁨year⁩ ago

  The epitome of this classic video

  source

  • thingsiplay@kbin.social ⁨1⁩ ⁨year⁩ ago

    A typical Reddit discussion.

    source