ターミナルエミュレータの概要

私たちの翻訳局から一言: 通常、誰もが最新の資料や出版物の翻訳に努めていますが、私たちも例外ではありません。 しかし、端末は週に一度アップデートされるものではありません。 そこで、2018 年春に発表されたアントワーヌ ボープレによる記事を翻訳しました。現代の基準からするとかなりの「古さ」にもかかわらず、私たちの意見では、この資料はその関連性をまったく失っていません。 なお、当初はXNUMX回の連載でしたが、XNUMX回の大きな記事にまとめることにしました。

ターミナルはコンピュータの歴史の中で特別な位置を占めていますが、ここ数十年、グラフィカル インターフェイスが普及するにつれてコマンド ラインと並んで生き残らざるを得なくなりました。 ターミナルエミュレータ 自分のものと交換した ハードウェア兄弟、つまり、パンチカードとトグルスイッチに基づいたシステムの修正でした。 最新のディストリビューションには、あらゆる形状や色のさまざまなターミナル エミュレーターが付属しています。 そして、多くの人は自分の作業環境で提供される標準のターミナルに満足していますが、中には、お気に入りのシェルやテキスト エディタを実行するために、まったく風変わりなソフトウェアを誇らしげに使用している人もいます。 ただし、この記事からわかるように、すべての端末が同じイメージで作成されているわけではありません。機能、サイズ、パフォーマンスが大きく異なります。

一部の端末には、まったく驚くべきセキュリティ ホールがあり、さらにほとんどの端末には、タブ付きインターフェイスのサポートからスクリプト作成まで、まったく異なる機能セットが備わっています。 私たちは 遠い過去に端末エミュレータを検討した, この記事は、読者が 2018 年に使用する端末を決定するのに役立つ以前の資料を更新したものです。 記事の前半では機能を比較し、後半ではパフォーマンスを評価します。

私がレビューした端末は次のとおりです。

執筆時点では Debian 9 または Fedora 27 で展開できた安定ビルドに限定されていたため、これらは最新バージョンではない可能性があります。唯一の例外は Alacritty です。 これは GPU アクセラレーション端末の子孫であり、このタスク用に珍しい新しい言語である Rust で書かれています。 Web 端末をレビューから除外しました ( 電子）、予備テストで非常に悪いパフォーマンスが示されたためです。

Unicode のサポート

Unicode サポートを使用してテストを開始しました。 端末の最初のテストは、Unicode 文字列を表示することでした。 ウィキペディアの記事: 「é、Δ、И、ק、م、๗、あ、叶、葉、말」 この簡単なテストは、端末が世界中で正しく動作できるかどうかを示します。 xterm 端末にアラビア文字が表示されない Mem デフォルト設定では:

デフォルトでは、xterm は古典的な「固定」フォントを使用します。 相変わらずのヴィッキー、「1997 年以来、Unicode をかなりカバーしている」。 このフォントでは文字が空白のフレームとして表示される問題が発生しており、文字が最終的に正しく表示されるのは、テキスト フォントが 20 ポイント以上に増加した場合のみです。 ただし、この「修正」により、他の Unicode 文字の表示が壊れます。

これらのスクリーンショットは、一部の古いバージョンの端末 (特に mlterm) がフォントを適切に処理できなかった Debian 27 よりも良好な結果が得られたため、Fedora 9 で撮影されました。 幸いなことに、これは後のバージョンで修正されました。

ここで、xterm で行がどのように表示されるかに注目してください。 記号Memとそれに続くセム語であることが判明しました クフ RTL スタイル スクリプト (右から左へ)、技術的には右から左に表示される必要があります。 Firefox 57 などの Web ブラウザは、上記の行を正しく処理します。 RTL テキストのより単純なバージョンは、「」という単語です。サラ「ヘブライ語で（<XNUMXxDXNUMX><XNUMXxDXNUMX><XNUMXxAXNUMX><XNUMXxDXNUMX><XNUMXxDXNUMX><XNUMXxDXNUMX>). 双方向テキストに関する Wiki ページ は次のように述べています。

「多くのコンピューター プログラムは双方向テキストを正しく表示できません。 たとえば、ヘブライ語の名前「サラ」は、sin (ש) (右側に表示される)、次に resh (ר)、そして最後に he (ה) (左側に表示される) の文字で構成されます。

多くの端末はこのテストに合格しません。Alacritty、VTE 由来の Gnome および XFCE 端末、urxvt、st、および xterm は、あたかも名前を「Aras」と書いたかのように、「Sara」を逆の順序で表示します。

双方向テキストに関するもう XNUMX つの問題は、特に RTL テキストと LTR テキストを混合する場合、何らかの方法で位置を揃える必要があることです。 RTL スクリプトはターミナル ウィンドウの右側から実行する必要がありますが、デフォルトで LTR 英語に設定されているターミナルではどうすればよいでしょうか? それらのほとんどには特別なメカニズムはなく、すべてのテキストが左に揃えられます (Konsole を含む)。 例外は pterm と mlterm で、これらは標準に準拠し、そのような行を右揃えにします。

挿入保護

私が認識した次の重要な機能は、挿入防止保護です。 次のような呪文があることは広く知られていますが、

$ curl http://example.com/ | sh

はコード実行のプッシュ コマンドですが、注意深く調べた後でも、Web ブラウザからコピー アンド ペーストするときに隠しコマンドがコンソールに忍び込む可能性があることを知っている人はほとんどいません。 検証サイト Gianna Horna このコマンドがいかに無害に見えるかを見事に示しています。

git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git

Horn の Web サイトから端末に貼り付けると、非常に迷惑なコードになります。

git clone /dev/null;
    clear;
	echo -n "Hello ";
	whoami|tr -d 'n';
	echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust! 
	Here'"'"'s the first line of your /etc/passwd: ';
	head -n1 /etc/passwd
	git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

使い方？ ブロック内に悪意のあるコードが含まれている 、CSS を使用してユーザーのビューから移動されます。

括弧内貼り付けモード は明らかにそのような攻撃を無力化するように設計されています。 このモードでは、端末は貼り付けたテキストを XNUMX 対の特別なエスケープ シーケンスで囲み、テキストの起源をシェルに伝えます。 これにより、貼り付けられたテキストに含まれる可能性のある特殊文字を無視できることがシェルに伝えられます。 由緒ある xterm までのすべての端末はこの機能をサポートしていますが、括弧付きモードで貼り付けるには、端末上で実行されているシェルまたはアプリケーションからのサポートが必要です。 たとえば、次のようなソフトウェアを使用します。 GNU リードライン (同じBash)、ファイルが必要です ~/.inputrc:

set enable-bracketed-paste on

残念ながら、Horn のテスト サイトには、テキストの書式設定自体によってこの保護を回避し、途中で括弧付きモードを適用してしまう方法も示されています。 これが機能するのは、一部の端末が独自のエスケープ シーケンスを追加する前にエスケープ シーケンスを正しくフィルタリングしないためです。 たとえば、私の環境では、正しい構成であっても、Konsole テストを正常に完了することができませんでした。 .inputrc ファイル。 これは、サポートされていないアプリケーションや不適切に構成されたシェルが原因で、システム構成が簡単に破損する可能性があることを意味します。 これは、慎重な構成作業があまり一般的ではないリモート サーバーにログインする場合、特にそのようなリモート マシンが多数ある場合に特に危険です。

この問題に対する良い解決策は、ターミナルの貼り付け確認プラグインです。 ウルクスブト、改行を含むテキストを挿入する許可を求めるだけです。 Horn が説明したテキスト攻撃に対して、これより安全なオプションは見つかりませんでした。

タブとプロファイル

現在人気のある機能は、タブ付きインターフェイスのサポートです。これを、他のいくつかの端末を含む XNUMX つの端末ウィンドウとして定義します。 この機能は端末ごとに異なり、従来の xterm 端末はタブをまったくサポートしていませんが、Xfce 端末、GNOME 端末、Konsole などのより新しい端末にはこの機能があります。 Urxvt はタブもサポートしますが、プラグインを使用する場合のみです。 しかし、タブのサポート自体に関しては、Terminator が議論の余地のないリーダーです。タブをサポートするだけでなく、端子を任意の順序で配置することもできます (下の画像を参照)。

Terminator のもう XNUMX つの機能は、これらのタブを「グループ化」し、同じキーストロークを複数の端末に同時に送信する機能で、複数のサーバー上で一括操作を同時に実行するための粗雑なツールを提供します。 同様の機能が Konsole にも実装されています。 他の端末でこの機能を使用するには、次のようなサードパーティ製ソフトウェアを使用する必要があります。 クラスターSSH, ゆるい または tmux.

タブは、プロファイルと組み合わせると特に効果的に機能します。たとえば、メール用に XNUMX つのタブ、チャット用に別のタブを作成することができます。 これは、Konsole ターミナルと GNOME ターミナルで十分にサポートされています。 どちらも、各タブで独自のプロファイルを自動的に起動できます。 Terminator はプロファイルもサポートしていますが、特定のタブを開いたときに特定のプログラムを自動的に起動する方法が見つかりませんでした。 他の端末には「プロファイル」という概念が全くありません。

フリル

この記事の最初の部分で最後に説明するのは、端末の外観です。 たとえば、GNOME、Xfce、urxvt は透明性をサポートしていますが、最近背景画像のサポートを終了したため、一部のユーザーはターミナルへの切り替えを余儀なくされています。 ティリックス。 個人的にはシンプルで満足です Xリソース、urxvt の背景色の基本セットを設定します。 ただし、標準以外のカラーテーマも問題を引き起こす可能性があります。 例えば、 ソラリゼーション 動作しません アプリケーション付き htopの и IPトラフィック、すでに独自の色を使用しているためです。

オリジナルVT100端子 は色をサポートしておらず、新しい色は 256 色のパレットに制限されることがよくありました。 端末のスタイルを設定する上級ユーザーにとって、複雑な方法でシェル プロンプトやステータス バーが煩わしい制限となる場合があります。 要旨 どの端末が「True Color」をサポートしているかを追跡します。 私のテストでは、st、Alacritty、および VTE ベースの端末が True Color を完全にサポートしていることを確認しています。 他の端末はこの点であまりうまく機能しておらず、実際には 256 色さえも表示できません。 以下に、GNOME 端末での True Color サポートの違いを示します。st と xterm は 256 カラー パレットでこれをうまく機能しますが、urxvt はテストに失敗するだけでなく、代わりにいくつかの点滅する文字を表示します。

端末によっては、URL パターンのテキストを分析して、リンクをクリック可能にすることもあります。 これはすべての VTE 派生端末に当てはまりますが、urxvt ではクリックまたはキーボード ショートカットを使用して URL を変換する特別なプラグインが必要です。 私がテストした他の端末では、別の方法で URL が表示されます。

最後に、端末における新しいトレンドは、スクロール バッファーのオプションです。 たとえば、st にはスクロール バッファーがありません。 ユーザーは tmux などの端末マルチプレクサを使用することを想定しています。 GNUスクリーン.

Alacritty にはバックスクロール バッファーもありませんが、 すぐに追加されます このトピックに関するユーザーからの「広範なフィードバック」が支持されています。 これらの新興企業は別として、私がテストした中で見つかったすべての端末は逆スクロールをサポートしています。

小計

資料の XNUMX 番目の部分 (オリジナルでは、これらは XNUMX つの異なる記事でした。 レーン) パフォーマンス、メモリ使用量、遅延を比較します。 しかし、問題の端末の一部には重大な欠陥があることがすでにわかります。 たとえば、RTL スクリプトを定期的に使用するユーザーは、他のユーザーよりも同様のタスクを処理するのが得意であるため、mlterm と pterm を検討するとよいでしょう。 コンソールも好調だった。 RTL スクリプトを使用しないユーザーは、他のものを選択できます。

悪意のあるコードの挿入に対する保護という点では、このタイプの攻撃に対する保護を特別に実装している urxvt が際立っており、私にとっては間違いなく便利だと思われます。 付加機能を探している人にとって、Konsole は一見の価値があります。 最後に、VTE はカラー サポートや URL 認識などを保証する端末の優れたベースであることは注目に値します。 一見すると、好みの環境に付属するデフォルトの端末がすべての要件を満たしているように見えますが、パフォーマンスを理解するまでこの質問は保留しておきます。

会話を続けます

一般に、端末のパフォーマンス自体は現実離れした問題のように思えるかもしれませんが、実際には、端末の中には、このような基本的な種類のソフトウェアに対して驚くほど高い遅延を示すものもあります。 また次に、伝統的に「速度」と呼ばれるもの (実際には、これはスクロール速度です) と端末のメモリ消費量を見ていきます (これは、今日では数十年前ほど重要ではないことに注意してください)。

遅れ

端末のパフォーマンスを徹底的に調査した結果、この点で最も重要なパラメータは遅延 (ping) であるという結論に達しました。 彼の記事では 「喜んで印刷いたします」 Pavel Fatin 氏は、さまざまなテキスト エディターの遅延を調べ、この点で端末が最も速いテキスト エディターよりも遅い可能性があることを示唆しました。 最終的に私が独自のテストを実行し、この記事を書くきっかけとなったのは、このヒントでした。

しかし、レイテンシーとは何ですか?なぜそれほど重要なのでしょうか? Fatin 氏は記事の中で、これを「キーを押してから対応する画面が更新されるまでの遅延」と定義し、引用しました。 「ヒューマン・コンピュータ・インタラクションガイド」には、「コンピュータディスプレイ上の視覚的フィードバックの遅れは、タイピストの行動と満足度に重要な影響を与える。」と述べられています。

Fatin 氏は、この ping には単なる満足以上の深い影響があると説明しています。「タイピングが遅くなり、エラーが増え、目と筋肉の緊張が高まる」のです。 つまり、遅延が大きいとタイプミスが発生したり、脳にさらなる認知負荷がかかるため、コードの品質が低下したりする可能性があります。 しかし、さらに悪いことに、ping は「目と筋肉の緊張を増大させる」ということです。 労働災害の発生 将来は （どうやら、著者は目、背中、腕、そしてもちろん視力の筋肉の問題を意味しているようです。 レーン）繰り返しのストレスが原因です。

これらの効果のいくつかは長い間知られており、その結果は 研究1976年にエルゴノミクス誌に発表された論文では、100ミリ秒の遅延は「タイピング速度に重大な影響を与える」と述べています。 最近では、GNOME ユーザー ガイドが導入されました。 許容可能な応答時間 10 ミリ秒以内、さらに進むと、 マイクロソフトリサーチ は 1 ミリ秒が理想的であることを示しています。

Fatin はテキスト エディタでテストを実施しました。 彼は、と呼ばれるポータブル楽器を作成しました。 タイポメーター、ターミナルエミュレータでpingをテストするために使用しました。 テストはシミュレーション モードで実施されたことに留意してください。実際には、入力 (キーボード、USB コントローラーなど) と出力 (ビデオ カード バッファ、モニター) の両方の遅延を考慮する必要があります。 Fatin 氏によると、一般的な構成では約 20 ミリ秒です。 ゲーム機器をお持ちの場合は、わずか 3 ミリ秒でこの数字を達成できます。 すでに非常に高速なハードウェアがあるため、アプリケーションは独自のレイテンシーを追加する必要がありません。 Fatin の目標は、アプリケーションの遅延を 1 ミリ秒にすること、あるいはダイヤルなしでダイヤルできるようにすることです。 測定可能な遅延、どのように インテリジェントIDEA 15.

私の測定結果と Fatin の結果の一部は、私の実験が彼のテストと一致することを示しています。

最初に驚いたのは、xterm や mlterm などの古いプログラムの応答時間が向上していることです。 最悪のレジスタ レイテンシー (2,4 ミリ秒) では、最速の最新端末 (st で 10,6 ミリ秒) よりも優れたパフォーマンスを発揮しました。 最新の端末では 10 ミリ秒のしきい値を下回ることはありません。 特に、Alacritty は、2017 年の最初のレビュー以来スコアが向上していますが、「利用可能な最速のターミナル エミュレーター」という要求を満たしていません。 実際、このプロジェクトの作者たちは、 状況を認識している 表示の改善に取り組んでいます。 GTK3 を使用する Vim は、対応する GTK2 よりも一桁遅いことにも注意してください。 このことから、GTK3 によって追加のレイテンシーが発生し、これが GTK4 を使用する他のすべての端末 (ターミネーター、XfceXNUMX ターミナル、および GNOME ターミナル) に反映されると結論付けることができます。

ただし、違いは目には見えない場合があります。 Fatin 氏は、「遅延が影響するのに、遅延を意識する必要はありません」と説明しています。 Fatin 氏はまた、標準偏差についても警告しています。「遅延 (ジッター) の乱れは、予測不可能であるため、さらなるストレスを生み出します。」

上のグラフは、純粋な Debian 9 (ストレッチ) で取得したものです。 i3ウィンドウマネージャー。 この環境では、レイテンシ テストで最良の結果が得られます。 結局のところ、GNOME はすべての測定に対して 20 ミリ秒の追加の ping を作成します。 これについては、入力イベントの同期処理を行うプログラムの存在が考えられます。 ファティンはそのような場合の例を示しています ワークレーブ、すべての入力イベントを同期的に処理することで遅延を追加します。 デフォルトでは、GNOME にはウィンドウ マネージャーも付属しています 母追加のバッファリング層が作成され、ping に影響し、少なくとも 8 ミリ秒の遅延が追加されます。

スクロール速度

次のテストは従来の「速度」または「帯域幅」テストで、画面上に大量のテキストを表示しながら端末がページをスクロールできる速度を測定します。 テストの仕組みはさまざまです。 元のテストは、seq コマンドを使用して同じテキスト文字列を単純に生成することでした。 他のテストには、Thomas E. Dickey (xterm メンテナ) のテストが含まれます。 terminfo.src ファイルがダウンロードされます。 端末のパフォーマンスの別のレビューでは デン・ルー ランダムなバイトの Base32 エンコード文字列を使用し、cat を使用して端末に出力します。 Luu 氏は、そのようなテストは「想像できるほど役に立たないベンチマーク」であると考えており、代わりに端末の応答を主要な指標として使用することを提案しています。 ディッキー氏はまた、彼のテストは誤解を招くものだとも言っている。 ただし、どちらの著者も、ターミナル ウィンドウの帯域幅が問題になる可能性があることを認めています。 Luu は、大きなファイルを表示すると Emacs Eshell がフリーズすることを発見し、Dickey は端末を最適化して xtrerm の視覚的な遅さを解消しました。 したがって、このテストにはまだいくつかの利点がありますが、レンダリング プロセスは端末ごとに大きく異なるため、他のパラメータをテストするためのテスト コンポーネントとしても使用できます。

ここでは、rxvt と st が競合他社をリードし、その後にパフォーマンスを重視して設計されたはるかに新しい Alacritty が続きます。 次に Xfce (VTE ファミリ) と Konsole があり、ほぼ XNUMX 倍高速です。 最後は xterm ですが、これは rxvt より XNUMX 倍遅いです。 テスト中、xterm もかなり波打ち、同じ行であっても通過するテキストが見にくくなりました。 Konsole は高速でしたが、時々表示がフリーズし、部分的なテキストが表示されたり、まったく表示されなかったりすることがありました。 st、Alacritty、rxvt などの他の端末では文字列が明確に表示されました。

Dickey 氏は、パフォーマンスの違いは端末ごとのスクロール バッファの設計によるものだと説明しています。 特に彼は、rxvt やその他の端末が「一般規則に従っていない」と非難しています。

「xterm とは異なり、rxvt はすべての更新を表示しようとしませんでした。 遅れている場合は、追いつくために一部の更新を拒否します。 これは、内部メモリ構成よりも見かけのスクロール速度に大きな影響を与えました。 欠点の XNUMX つは、ASCII アニメーションがやや不正確だったことです。」

この認識された xterm の遅さを修正するには、Dickey は次のリソースを使用することを提案しています。 高速スクロールこれにより、xterm はフローに対応するために一部の画面更新を破棄できるようになります。 私のテストでは、fastScroll によってパフォーマンスが向上し、xterm が rxvt と同等になることが確認されました。 ただし、Dickey 自身が次のように説明しているように、これはかなり厳しい問題です。「いくつかの画面が削除された後、新しい一連の画面更新を待っているため、konsole と同様に xterm が停止することがあります。」 この流れで、他の端末は速度と表示の完全性の間の最良の妥協点を見つけたようです。

資源の消費

パフォーマンスの指標としてスクロール速度を考慮することが理にかなっているかどうかに関係なく、このテストにより端末の負荷をシミュレートできるようになり、メモリやディスクの使用量などの他のパラメータを測定できるようになります。 メトリクスは、指定されたテストを実行することによって取得されました seq Python プロセス監視の下で。 彼はメーターのデータを収集した ゲトルセージ() のために ru_maxrss、 額 ru_oublock и ru_inblock そしてシンプルなタイマー。

このテストでは、ST が 8 MB という最小の平均メモリ消費量で 12 位になりました。設計の主な考え方がシンプルであることを考慮すると、これは驚くべきことではありません。 mlterm、xterm、および rxvt はもう少し多く (約 30 MB) を消費します。 もう 40 つの注目すべき結果は、実行に 60 MB を必要とする Alacritty です。 次に、65 MB から XNUMX MB という数字を持つ VTE ファミリの端末もあり、これはかなりの量です。 この消費量は、これらの端末が GTK などの高レベルのライブラリを使用しているという事実によって説明できます。 Konsole はテスト中に XNUMXMB という驚異的なメモリ消費量で最下位になりましたが、これはその非常に幅広い機能によって正当化される可能性があります。

4 年前に得られた以前の結果と比較すると、すべてのプログラムが著しく多くのメモリを消費し始めました。 Xterm は以前は 15 MB を必要としていましたが、現在は起動時だけで 16 MB を必要とします。 rxvt の消費量も同様に増加しており、すぐに 34 MB が必要になります。 Xfce ターミナルは 20 MB を消費しますが、これは以前の 32 倍の大きさですが、GNOME ターミナルは 2012 MB しか必要としません。 もちろん、これまでのテストはすべて XNUMX ビット アーキテクチャで実行されました。 LCA XNUMXにて ラスティ・ラッセル рассказал、メモリ消費量の増加を説明できる微妙な理由がたくさんあると考えられます。 とはいえ、今はメモリがギガバイトある時代ですから、なんとかなるでしょう。

しかし、端末のような基本的なものにさらに多くのメモリを割り当てるのはリソースの無駄であると感じずにはいられません。 これらのプログラムは最小のものでなければならず、Linux システムを搭載する必要がある場合には、靴箱であっても、どんな「箱」でも実行できる必要があります (そして、実際にはそうなることはご存知でしょう) ）。 しかし、これらの数字を考えると、メモリ使用量は、最も軽量で機能が最も制限されている少数の端末を除いて、複数の端末を実行する環境では将来的に問題になるでしょう。 これを補うために、GNOME ターミナル、Konsole、urxvt、Terminator、および Xfce ターミナルにはデーモン モードがあり、単一プロセスを通じて複数のターミナルを制御し、メモリ消費を制限できます。

テスト中に、ディスクの読み書きに関して、別の予期せぬ結果が得られました。ここでは何も表示されないと予想していましたが、一部の端末が最も大量のデータをディスクに書き込むことが判明しました。 したがって、VTE ライブラリは実際にはディスク上にスクロール バッファを保持します (この機能は 2010年に注目されました、そしてこれは今でも起こっています）。 ただし、古い実装とは異なり、現在では少なくともこのデータは AES256 GCM を使用して暗号化されています (バージョン0.39.2から）。 しかし、当然の疑問が生じます。VTE ライブラリの何がそんなに特別で、実装にそのような非標準的なアプローチが必要になるのでしょうか...

まとめ

この記事の最初の部分では、VTE ベースの端末には優れた機能セットがあることがわかりましたが、これにはある程度のパフォーマンスのコストが伴うことがわかりました。 すべての VTE 端末はデーモン プロセスを通じて制御できるため、メモリは問題になりません。これにより、端末の要求が制限されます。 ただし、RAM とカーネル バッファの量に物理的な制限がある古いシステムでは、消費するリソースが大幅に少ないため、以前のバージョンの端末が必要になる場合があります。 VTE 端末はスループット (スクロール) テストでは良好なパフォーマンスを示しましたが、表示遅延が GNOME ユーザー ガイドで設定されたしきい値を超えています。 VTE 開発者はおそらくこれを考慮する必要があります。 Linux 初心者にとってもターミナルに遭遇するのは避けられないことを考慮すれば、Linux をより使いやすくすることができます。 経験豊富なマニアにとっては、デフォルトの端末から切り替えることで目の疲れが軽減され、長時間の作業による将来の仕事関連の怪我や病気を回避できる可能性さえあります。 残念ながら、古い xterm と mlterm だけが 10 ミリ秒という魔法の ping しきい値に達しますが、これは多くの人にとって受け入れられません。

ベンチマーク測定では、Linux グラフィカル環境の発展により、開発者が多くの妥協をしなければならないことも分かりました。 ユーザーによっては、ping を大幅に削減できる通常のウィンドウ マネージャーを検討する場合があります。 残念ながら、Wayland のレイテンシーを測定することはできませんでした。私が使用した Typometer プログラムは、Wayland が他のウィンドウをスパイすることを防止するために作成されたものでした。 Wayland 合成のパフォーマンスが X.org よりも優れていることを願っています。また、将来的には誰かがこの環境でレイテンシーを測定する方法を見つけてくれることも願っています。

出所： habr.com