Linux Terminal Emulators Have The Potential Of Being Much Faster

[EphemeralEft]

Have you tried Hamster? It can be insanely fast at times, but only in circles.

Versions of Hamster reach EOL far too quickly.

[jengelh]

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.

Speed isn't the point—latency is. And none of the newfangled stuff really lives up to it, based on a 2018 measurement.

[mb_q]

The foot author on the differences between foot & alacritty (tl;dr -- alacritty repaints everything on change, while foot just the damaged regions): https://codeberg.org/dnkl/foot/wiki/Performance

[danger]

What's with the 5 different window decorations on that screenshot? Ah, I know. It's the GNOME CSD and Wayland that make your desktop look like shit.

[reba]

What's with the 5 different window decorations on that screenshot? Ah, I know. It's the GNOME CSD and Wayland that make your desktop look like shit.

Nope, just CSD. On Plasma and labwc, which support SSD, everything looks like made out of one hand.

[timofonic]

Oh no! Terminal emulator OCD!

A faster one appears, it misses a feature I like and has more latency. A less latency one appears, it misses abfeature and has more latency. There are worse cases, worse ones with nearly zero features and slow like a crawl.

Why not put that effort to make a universal terminal emulator library that doesn't suck, used by major DEs/WMs, tooolkit agnostic and even used by framebuffer stuff so killing classic kernel console with fire? Kmscon and libtsm (discontinued with minor forks) were a great concept. There's stuff like yaft (discontinued), but foot seems alive.

Scrolling keeps sucking on Linux, but it's not better in Windows omand Mac too.

There's the latency issue too. Anyway, I see too much code duplication these days and suboptimal solutions everywhere. People only care about overloaded application frameworks, it's pathetic.

Using Java for measuring latency is very funny! It's crazily hilarious that Typometer was coded in Java, anyway.

[Guest]

What a load of crap.
I can claim that I invented teleport prototyoe that can teleport a small ant but won't develop it further. Because reasons.

Such load of bullcrap can come only from gnome "developer". serious people would never allow themselves something like that

[Ironmask]

Why not put that effort to make a universal terminal emulator library that doesn't suck, used by major DEs/WMs, tooolkit agnostic and even used by framebuffer stuff so killing classic kernel console with fire? Kmscon and libtsm (discontinued with minor forks) were a great concept. There's stuff like yaft (discontinued), but foot seems alive.

Scrolling keeps sucking on Linux, but it's not better in Windows omand Mac too.

There's the latency issue too. Anyway, I see too much code duplication these days and suboptimal solutions everywhere. People only care about overloaded application frameworks, it's pathetic.

Most Linux stuff is still, sadly, coded in C/C++ which are impossible to do much code sharing in. I honestly find it funny when people look at how easy it is to reuse Rust code and how every Rust program is made out of multiple packages and the C++ people are just bewildered by it. Then they say it's a point of failure because JavaScript does it this way which is a huge security hole, nevermind Java, C# and Python have been doing it this way for a good decade with almost no issues.
It's still really hard to share code in C/C++, you have to manually download it and integrate it into your build system and make sure theres no clashes or compiler errors. It's really no wonder why everything basically just depends on glibc and has to re-implement Common Lisp to do anything else.

Using Java for measuring latency is very funny! It's crazily hilarious that Typometer was coded in Java, anyway.

Java is virtually just as fast as native code, it's JIT compiled at launch. It takes forever to startup since the runtime is essentially compiling the code, but once it's up, it's lightening fast. Don't hold a cargo cult belief that "fast code" needs to be compiled only once to be good. The only limiting factor in JIT compiled languages is runtime performance, like Python's GIL which basically make Python useless, or Java and .NET's stop-the-world garbage collectors, which Java has been making great strides to reduce the impact of.

[NobodyXu]

Ironmask I agree with most of your comment, but regarding JIT compilation, another problem with it is the memory usage of the runtime, which is a much harder-to-improve metric when comparing Java and Python against compiled languages without GC such as Rust, C, C++, etc.

From what I read though, while Go also has a GC its memory usage is much better than Java and more on par with Rust, C and C++.
I read that Go has a much simpler GC without auto de-fragmentation and other features and that is part of the reason why it takes much less memory.

Other reason might be it is a compiled language with no OOP, hence it doesn't need any JIT compilation, no virtual table/inheritance/up/down casting etc and thus require less code/data structure in binary and in runtime.

[anarki2]

"Everyone's lame, mine is the bestest, but you can't have it"

So what's even the point of such sh*tposting, really? What a joke.