TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How much faster are the Gnome 46 terminals?

521 点作者 janvdberg大约 1 年前

36 条评论

dwheeler大约 1 年前
Hooray, with these changes, the tested setup finally manages to have a smaller input median latency (Console ~12 msec) than an Apple &#x2F;&#x2F;e from 1983 (30 msec). It only took 41 years: <a href="https:&#x2F;&#x2F;www.extremetech.com&#x2F;computing&#x2F;261148-modern-computers-struggle-match-input-latency-apple-iie" rel="nofollow">https:&#x2F;&#x2F;www.extremetech.com&#x2F;computing&#x2F;261148-modern-computer...</a> <a href="https:&#x2F;&#x2F;danluu.com&#x2F;input-lag&#x2F;" rel="nofollow">https:&#x2F;&#x2F;danluu.com&#x2F;input-lag&#x2F;</a><p>But wait! Not so fast (smile). This benchmark uses the compositor &quot;raw Mutter 46.0&quot;, <i>not</i> GNOME Shell. Raw mutter is &quot;a very bare-bones environment that is only really meant for testing.&quot;<p>In addition, this measurement is <i>not</i> end-to-end because it does not include keyboard latency. In this test, the &quot;board sends a key press over USB (for example, Space)&quot;. Latencies just within a keyboard can go up to 60msec by themselves: <a href="https:&#x2F;&#x2F;danluu.com&#x2F;keyboard-latency&#x2F;" rel="nofollow">https:&#x2F;&#x2F;danluu.com&#x2F;keyboard-latency&#x2F;</a><p>What are the true end-to-end numbers for the default configuration, which is the only situation and configuration that really matters? I wish the article had measured that. I suspect the numbers will be significantly worse.<p>I do congratulate the work of the GNOME team and the benchmarker here. Great job! But there are important unanswered questions.<p>Of course, the Apple &#x2F;&#x2F;e used hardware acceleration and didn&#x27;t deal with Unicode, so there are many differences. Also note that the Apple &#x2F;&#x2F;e design was based on the older Apple ][, designed in the 1970s.<p>Still, it would be nice to return to the human resposiveness of machines 41+ years old.
评论 #39970463 未加载
评论 #39972719 未加载
评论 #39969385 未加载
评论 #39968679 未加载
评论 #39969486 未加载
评论 #39969703 未加载
评论 #39970561 未加载
评论 #39969564 未加载
评论 #39983211 未加载
评论 #39996772 未加载
评论 #39973369 未加载
评论 #39969884 未加载
评论 #39972975 未加载
评论 #39969854 未加载
unwind大约 1 年前
Very nice!<p>I love both the underlying focus on performance by the VTE developers, and the intense hardware-driven measurement process in the article!<p>The use of a light sensor to measure latency reminded me of Ben Heck&#x27;s clearly named &quot;Xbox One Controller Monitor&quot; [1] product [1] which combines direct reading of game console controller button states with a light sensor to help game developers keep their latency down. It looks awesome, but it&#x27;s also $900.<p>[1]: <a href="https:&#x2F;&#x2F;www.benheck.com&#x2F;xbox1monitor&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.benheck.com&#x2F;xbox1monitor&#x2F;</a>
评论 #39967517 未加载
评论 #39969896 未加载
stinos大约 1 年前
This, and the linked article, show the photo sensor halfway the monitor. Nothing wrong with that for comparing measurements, but for quite a lot (possibly the majority) of typical monitors out there that actually means for a refresh of 60Hz putting the sensor at the top of the screen will give you about 8mSec faster and at the bottom 8mSec slower measurements because pixels &#x2F; lines thereof are driven top to bottom. Like a CRT basically. So if you&#x27;re getting into the details (just like where to put the threshold on the photo sensor signal to decide when the pixel is on) that should probably be mentioned. Also because 8mSec is quite the deal when looking at the numbers in tha article :)<p>Likewise just saying &#x27;monitor x&#x27; is 30mSec slower than &#x27;monitor y&#x27; can be a bit of a stretch; it&#x27;s more like &#x27;I measured this to be xxmSec slower on my setup with settings X and Y and Z&#x27;. I.e. should also check if the monitor isn&#x27;t applying some funny &#x27;enhancement&#x27; adding latency with no perceivable effect but which can be turned off, whether when switching monitors your graphics card and&#x2F;or its driver didn&#x27;t try to be helpful and magically switched to some profile where it tries to apply enhancements, corrections, scaling and whatnot which add latency. All without a word of warning from said devices usually, but these are just a couple of the things I&#x27;ve seen.
评论 #39970826 未加载
robotburrito大约 1 年前
It&#x27;s crazy to me we exist in a world where we can render hyper realistic 3d scenes and play games that once felt like they would be impossible to render on consumer grade hardware AND in the world where we are still trying to perfect putting text on a screen for a terminal LOL :)
评论 #39972263 未加载
评论 #39971726 未加载
l33tman大约 1 年前
Not related to the speed, but is there any terminal for Linux that works like the Mac OSX terminal, in that you can shut it down and restart and it will bring up all the tabs and their cmd histories and scrollbacks for each tab? They do that by setting different bash history files for each tab etc.<p>And I prefer GUI terminals for this use-case...
评论 #39968427 未加载
评论 #39968389 未加载
评论 #39968327 未加载
评论 #39968242 未加载
评论 #39971795 未加载
评论 #39970151 未加载
评论 #39968692 未加载
评论 #39969440 未加载
评论 #39969953 未加载
评论 #39968301 未加载
评论 #39970204 未加载
评论 #39968428 未加载
评论 #39969612 未加载
评论 #39970010 未加载
评论 #39969782 未加载
INTPenis大约 1 年前
I used Gnome for years, then switched to sway and alacritty 2 years ago and honestly I can&#x27;t tell any difference. I guess this is just like high end audio equipment, my ears&#x2F;eyes are not tuned to the difference.
评论 #39968556 未加载
评论 #39968338 未加载
评论 #39971613 未加载
评论 #39968815 未加载
评论 #39972301 未加载
评论 #39968042 未加载
PhilipRoman大约 1 年前
Finally a terminal benchmark that isn&#x27;t just cat-ing a huge file. Would love to see the same test with a more diverse set of terminals, especially the native linux console.
评论 #39967210 未加载
codedokode大约 1 年前
Sorry for being off-topic but what I dislike the most about Gnome Terminal is that it opens a small window by default (like 1&#x2F;4 of my screen size) and even if you resize it, it doesn&#x27;t remember the size after restart. It turns out you need to go to settings and manually specify how many columns and rows do you want.
评论 #39970538 未加载
评论 #39970936 未加载
评论 #39973392 未加载
评论 #39971531 未加载
评论 #39969882 未加载
yla92大约 1 年前
Neat! Would love to see the benchmark to also include Mitchelle Hashimoto&#x27;s Ghostty terminal when it comes out publicly. (now still under development&#x2F;polishing stage and in private beta)<p><a href="https:&#x2F;&#x2F;mitchellh.com&#x2F;ghostty" rel="nofollow">https:&#x2F;&#x2F;mitchellh.com&#x2F;ghostty</a>
p_b_d大约 1 年前
I use xterm and i3wn on debian and I never experienced anything faster. Surely the idea of waste GPU for the terminal never even crossed my mind so alacritty is IMO overkill.
评论 #39970534 未加载
sprash大约 1 年前
I would be interested in a comparision of uncomposited X11 running Xterm using this measurement method.<p>Xterm outperforms everything &quot;on paper&quot; with typometer but is it really real?
评论 #39975073 未加载
评论 #39967615 未加载
larsrc大约 1 年前
Nice tests, but could you please use 0-based Y-axes in the charts? You&#x27;re visually exaggerating the improvements.
DiabloD3大约 1 年前
I don&#x27;t know what this has to do with &quot;terminals&quot;, other than the author is using this to benchmark this.<p>According to the author, Gnome 46&#x27;s Mutter, when in direct mode (which windowed apps <i>do not use</i>, so the benchmark is partially invalid; useful for gamers, but not much else) is faster.<p>Thats great. Gnome is now possibly as fast as all the wlroots-based Wayland WMs (Sway, River, Hyprland, etc) and KDE&#x27;s Kwin.<p>I&#x27;ve looked into why Mutter has historically been the worst WM on Linux for the longest time: it makes a lot of assumptions that &quot;smoother == better&quot;, no matter the cost. OSX&#x27;s WM does the same thing, so they felt justified.<p>If you lag more than 1 frame, it is noticeable to non-gamers; ergo, a latency of between 16 and 32ms (since WMs do not full-time VRR, although they could, and maybe should) once the app flushes their draw commands; this is on top of whatever the app did, which may also be assuming 60hz.<p>Modern WMs try to get latency down as far as possible, even implementing &quot;direct mode&quot; which directly displays the fullscreen app&#x27;s framebuffer, instead of compositing it, thus zero latency added by the WM itself.
评论 #39972716 未加载
tutfbhuf大约 1 年前
Just recently, I did a terminal latency test with Typometer for the following terminals, sorted by lowest latency:<p><pre><code> xterm (389-1) alacritty (0.13.1-1) kitty-tuned (0.31.0-1) zutty (0.14-2) st (master 95f22c5) urxvt (9.31-4) konsole (24.02.0-1) kitty (0.31.0-1) wezterm (20230712.072601) gnome-terminal (3.50.1-1) xfce4-terminal (1.1.1-2) terminator (2.1.3-3) tilix (1.9.6-3) hyper (v3.4.1) </code></pre> I only tested for software latency (monitor, keyboard and other hardware latency is not included in Typometer benchmarks). I ran the test on Arch Linux with Xorg + bswpwm without compositor. You can find the full results on by blog <a href="https:&#x2F;&#x2F;beuke.org&#x2F;terminal-latency&#x2F;" rel="nofollow">https:&#x2F;&#x2F;beuke.org&#x2F;terminal-latency&#x2F;</a>.
评论 #39969085 未加载
评论 #39967512 未加载
评论 #39968352 未加载
评论 #39968319 未加载
评论 #39968126 未加载
评论 #39971498 未加载
评论 #39967353 未加载
评论 #39970195 未加载
评论 #39967569 未加载
评论 #39967575 未加载
评论 #39967991 未加载
superkuh大约 1 年前
Speeding up the gnome terminal is useless whe you realize GNOME has been removing keyboard support features from Gtk since 2014.<p>Try to copy a file path from that Gnome 46 terminal and do a File-Open operation in a Gtk application and ctrl-v&lt;enter&gt; to paste in the path and open it.<p>Woops! Error! &quot;The folder contents could not be displayed. Operation not supported&quot;<p>GNOME and Gtk3&#x2F;4 no longer prioritize keyboard inputs and hide them behind complex key shortcuts. They let keyboard inputs bitrot and fail because they only care about GUI inputs. It&#x27;s an open bug since 2014, opened and closed as wontfix literally dozens of times. Brought up in #gtk chat a similar amount. Latest (2023) wontfix: <a href="https:&#x2F;&#x2F;gitlab.gnome.org&#x2F;GNOME&#x2F;gtk&#x2F;-&#x2F;issues&#x2F;5872" rel="nofollow">https:&#x2F;&#x2F;gitlab.gnome.org&#x2F;GNOME&#x2F;gtk&#x2F;-&#x2F;issues&#x2F;5872</a>
评论 #39973421 未加载
sevg大约 1 年前
I wonder how Kitty would do on these benchmarks.<p>Kitty is a different beast to Alacritty and has tonnes of features (many of which I&#x27;m grateful for), but I wonder what the performance cost is.
评论 #39967226 未加载
评论 #39967321 未加载
评论 #39967260 未加载
kazinator大约 1 年前
I can notice a slight latency in Gnome Terminal ... running in a VM ... on a Windows host ... being accessed via RDP over Wi-Fi and a 100 Mbps line. Not enough to bother me.
评论 #39967371 未加载
sscarduzio大约 1 年前
I appreciate the fine work done by developers and testers, however I&#x27;ve been using gnome-terminal for around two decades and never perceived the input latency.<p>Like, I installed Alacritty some years ago side-by-side with gnome-terminal, and gosh, I could not visually sense any difference. Do I have bad sight?
评论 #39967421 未加载
mseepgood大约 1 年前
Can anyone explain why a terminal needs &quot;speed&quot;? Isn&#x27;t the limiting factor the typing and reading speed of the human in front of it?
评论 #39967830 未加载
评论 #39968173 未加载
评论 #39970770 未加载
评论 #39967882 未加载
评论 #39968331 未加载
评论 #39980614 未加载
评论 #39969981 未加载
评论 #39971137 未加载
评论 #39967822 未加载
评论 #39971778 未加载
评论 #39968522 未加载
zokier大约 1 年前
I really appreciate doing actual end-to-end tests! The VTE improvements look great, good job!
Postosuchus大约 1 年前
Interesting timing (pun intended): apparently one of the recent Gnome updates in Ubuntu made terminal barely usable due to lagging - <a href="https:&#x2F;&#x2F;askubuntu.com&#x2F;questions&#x2F;1509058&#x2F;input-delay-on-terminal-ubuntu-22-04-4" rel="nofollow">https:&#x2F;&#x2F;askubuntu.com&#x2F;questions&#x2F;1509058&#x2F;input-delay-on-termi...</a><p>I&#x27;ve noticed this myself on my main rig running Ubuntu 22.04, which never ever had any perceptible lag. Now it is so bad I was forced to switch to Alacritty.
tverbeure大约 1 年前
Ironically, a bug in mutter crept into Ubuntu 22.04 and later just a week ago. It increased the keyboard latency dramatically on some systems and made typing a pain.<p>There&#x27;s currently a bug fix with update trial packages. The solution presented here worked for me: <a href="https:&#x2F;&#x2F;bugs.launchpad.net&#x2F;ubuntu&#x2F;+source&#x2F;mutter&#x2F;+bug&#x2F;2059847&#x2F;comments&#x2F;36" rel="nofollow">https:&#x2F;&#x2F;bugs.launchpad.net&#x2F;ubuntu&#x2F;+source&#x2F;mutter&#x2F;+bug&#x2F;205984...</a>
评论 #39971108 未加载
plingbang大约 1 年前
I used gnome-terminal for years and at the times when I had to switch to a virtual console, I often had a feeling that the latter was more responsive.<p>But that could be the placebo effect due to higher cursor blinking and key repeat rates. My monitor is 60 Hz.
aidenn0大约 1 年前
I remember many years ago, SBCL would build noticeably slower on gnome terminal as compared to xterm due to how verbose the build process was. I think they even put a note in the README about it.
nicolaslem大约 1 年前
My distro recently upgraded to Gnome 46 and as someone who spends a big chunk of their day in a terminal, the difference was very noticeable. Great work to everyone involved!
ghusbands大约 1 年前
They really need to start the y axis at 0 in those graphs - it&#x27;s somewhat misleading how low some of the latency bars appear.
bPspGiJT8Y大约 1 年前
Gnome terminal would also need some unicode handling improvements, its current score in `ucs-detect` rating is D-[0].<p>[0] <a href="https:&#x2F;&#x2F;ucs-detect.readthedocs.io&#x2F;results.html" rel="nofollow">https:&#x2F;&#x2F;ucs-detect.readthedocs.io&#x2F;results.html</a>
zokier大约 1 年前
there is lot of interesting stuff that could be measured here. Valves Gamescope is supposed to be this low-latency compositor, so it might be interesting to compare to more typical desktop compositors. Similarly testing VRR could have interesting results
tommi大约 1 年前
Well written article and interesting results, thank you.<p>I&#x27;m surprised that there has been input latency of tens of milliseconds with the said setup. How much are typical input latencies in comparable Windows laptops and Macs?
评论 #39967648 未加载
评论 #39971409 未加载
评论 #39967664 未加载
评论 #39967870 未加载
alberth大约 1 年前
Ghostty<p>I’m most interested in seeing the cross platform terminal named Ghostty, created by the creator of HashiCorp<p><a href="https:&#x2F;&#x2F;mitchellh.com&#x2F;ghostty" rel="nofollow">https:&#x2F;&#x2F;mitchellh.com&#x2F;ghostty</a>
pilcha大约 1 年前
&gt; terminal latency post &gt; xterm not mentioned :sadface:
nolist_policy大约 1 年前
The VTE improvements are very noticeable on the Pinephone btw.
eviks大约 1 年前
&gt; that is only really meant for testing. It is, however, quite useful for benchmarking,<p>But not very useful for real users<p>Although great that they are measuring real latency with a camera!
dyingkneepad大约 1 年前
The lack of mention to Linux&#x27;s power management system during measurement is worrying. This is the kind of test that gets completely affected by Linux power management policies, up to the point where results may be meaningless.
drewg123大约 1 年前
Personally, IDGAF about latency. I&#x27;m used to typing things into servers that are two crossings of a continent away (one for corp VPN entry, and then another one to get to a server 50 away via the cross-country VPN hop).<p>What gets me is the performance when a terminal command spews an unexpectedly large amount of output and&#x2F;or I forget to postpend less. Eg, the latency between ^C being entered and having an impact. This can be 10s of seconds on slower terminals like xterm and this is what finally got me to switch away from xterm to one of these new-fangled terminals like the one from lxde.
评论 #39971509 未加载
prmoustache大约 1 年前
&gt;Test Setup #<p>&gt;I did all tests on this system:<p>&gt; Lenovo Legion 7 Gen 7 AMD with Ryzen 7 6800H CPU and Radeon RX 6700M dGPU (using the dGPU exclusively via the MUX switch).<p>&gt; Monitor: Acer Nitro XV320QU, 2560×1440, 144 Hz, using 100% scale.<p>OK you can send these tests to the trashbin as this is so unrepresentative of what most users are using.<p>This is sometimes infuriating. A year ago, I installed linux on my partner&#x27;s computer, her HDD running windows had died.<p>Things were seemingly working fine until I realized some apps (dnfdragora comes to mind) were unusable on her 1366x768 with 1.x ratio as they take way too much screen estate. I think worldwide there are still more than 20% of desktop users using screen resolutions with less than 768px of height and around 50% of user with less than 900px of height.<p>I have not issue developpers using decent machines to develop, but when it comes to testing performance and usability they should also do it on that +10y old entry level laptop they probably still have sitting somewhere in a storage area. Or buy an old netbook for 20 bucks for that specific use.
评论 #39967899 未加载
评论 #39969141 未加载
评论 #39969695 未加载
评论 #39971192 未加载
评论 #39968084 未加载
评论 #39968328 未加载