GNOME Gets A New Terminal Choice: Prompt

[phoronix]

Phoronix: GNOME Gets A New Terminal: Prompt

A few months back GNOME developer Christian Hergert noted that Linux terminal emulators could be much faster following his experiments but then concluded at the time he didn't want to develop a new terminal becase "creating your own terminal is like 20 lines of code these days." Well, he ended up shifting stance a bit and has now announced Prompt, a new container-focused terminal emulator for the GNOME desktop...

https://www.phoronix.com/news/GNOME-Terminal-Prompt

[elduderino]

The way this article is titled is extremely misleading.

> GNOME Gets A New Terminal

No it doesn't. This is just an app I wrote by extracting various features from Builder. It's not GNOME default or any of that.

> he didn't want to develop a new terminal

And technically I didn't. I extracted something that has been in Builder for nearly a decade and polished it up with some standalone UI.

[indepe]

The way this article is titled is extremely misleading.

> GNOME Gets A New Terminal

No it doesn't. This is just an app I wrote by extracting various features from Builder. It's not GNOME default or any of that.

> he didn't want to develop a new terminal

And technically I didn't. I extracted something that has been in Builder for nearly a decade and polished it up with some standalone UI.

Since you are concerned with keyboard latency in general, may I ask regarding the performance of Wayland-based compositors which you mention in your blog, is there a significant lag between the actual key press, and the call to wl_keyboard_key in the wayland client ? I'm asking because that seems to be the only latency which can't be measured from within the app. I hope this question isn't too unrelated to what you would like to talk about here.

[elduderino]

I'm asking because that seems to be the only latency which can't be measured from within the app. I hope this question isn't too unrelated to what you would like to talk about here.

You definitely need a specialized hardware to really test this stuff as you want to test from press to display on physical screen.

Interestingly enough, someone has been doing that and tested the VTE performance work. It was in the same neighborhood as alacritty now (generally 20-30ms to display on a 60hz composited GNOME Shell IIRC). But I'm not up on all the details there. I'm sure they'll blog about it soon enough.

https://gitlab.gnome.org/GNOME/vte/-/issues/334

[treba]

Since you are concerned with keyboard latency in general, may I ask regarding the performance of Wayland-based compositors which you mention in your blog, is there a significant lag between the actual key press, and the call to wl_keyboard_key in the wayland client ? I'm asking because that seems to be the only latency which can't be measured from within the app. I hope this question isn't too unrelated to what you would like to talk about here.

Regarding Gnome: this used to be an issue until 42 and AFAIK pretty much solved. To give you an idea, this was one measurement from back then: https://gitlab.gnome.org/GNOME/mutte...5#note_1207054

[spyke]

Nice to see Asahi and a MacBook on the screenshot!

[indepe]

You definitely need a specialized hardware to really test this stuff as you want to test from press to display on physical screen.

Interestingly enough, someone has been doing that and tested the VTE performance work. It was in the same neighborhood as alacritty now (generally 20-30ms to display on a 60hz composited GNOME Shell IIRC). But I'm not up on all the details there. I'm sure they'll blog about it soon enough.

https://gitlab.gnome.org/GNOME/vte/-/issues/334

Thanks for the reference, that is interesting. It seems an overall average of 20 - 30ms from key press to display, is the current optimum on that system with a 144 Hz monitor (for the tested terminal apps).

[elduderino]

Nice to see Asahi and a MacBook on the screenshot!

Do note that if you try the Flatpak on Asahi, that for $REASONS the GL driver that gets selected is going to end up being llvm+zink. It's much faster if you build locally until that is resolved.

[indepe]

Regarding Gnome: this used to be an issue until 42 and AFAIK pretty much solved. To give you an idea, this was one measurement from back then: https://gitlab.gnome.org/GNOME/mutte...5#note_1207054

Thanks, I'll need to read more about what exactly was measured, but I think a mouse latency to client API call mostly below 2 ms would be good news. Especially considering it would be difficult to measure, and that other factors cause much more latency.

[mercutio]

% flatpak install --user --from https://nightly.gnome.org/repo/appst....Devel.flatpak
error: Can't load uri https://nightly.gnome.org/repo/appst...Devel.flatpak: Server returned status 404