Announcement

Collapse
No announcement yet.

GNOME Gets A New Terminal Choice: Prompt

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GNOME Gets A New Terminal Choice: Prompt

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      Originally posted by elduderino View Post
      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.

      Comment


      • #4
        Originally posted by indepe View Post
        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.

        As part of my effort to reduce input latency in Mutter, I built a latency tester similar to the one described in this post:

        Comment


        • #5
          Originally posted by indepe View Post

          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

          Comment


          • #6
            Nice to see Asahi and a MacBook on the screenshot!

            Comment


            • #7
              Originally posted by elduderino View Post

              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).

              Comment


              • #8
                Originally posted by spyke View Post
                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.

                Comment


                • #9
                  Originally posted by treba View Post

                  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.

                  Comment


                  • #10
                    % 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

                    Comment

                    Working...
                    X