端末エミュレーターはTTY 1-6と同じくらい高速ですか?


59

最近、組み込みのgnome-terminal、aterm、xterm、wtermからrxvtまで、さまざまなターミナルエミュレーターを試しています。私が行ってきたテストは次の順序です。

  1. 2つのペインでtmuxウィンドウを開きます
  2. 左ペインには、次のような詳細な集約型の作業になりますgrep a /et/c -rか、単純なtime seq -f 'blah blah %g' 100000
  3. 右側のペインは、構文がオンのvimウィンドウになり、100行を超えるコードを持つファイルを開きます。

左ペインが大量の出力を印刷しているとき、右ペインは非常に遅く応答しないようです。vimでスクロールしようとしましたが、変更するには1〜2秒かかります。CtrlC左ペインを押すと、停止するまで10秒以上待機します

TTYで同じこと(CTRL+ ALT+(F[1-6])を押す)を行うと、それは起こらず、両方のペインが非常に反応します。

アンチエイリアスフォント、カラーリングの有効化、デフォルト設定の使用、xmonadおよびopenboxへの変更など、いくつかの設定を変更しましたが、何も変更しません。

結果はtime seq -f 'blah blah %g' 100000これらの端末間で実際に違いはありませんが、特にspitted pane tmux(または他のマルチプレクサ)を実行している場合、応答性は本当に異なります。参考までに、私はそれらすべてを最大化モードで実行しています。

フレームバッファターミナルについて読んだことがありますが、どのように機能するか、またターミナルエミュレータを高速化するためにどのように使用できるかはわかりません。

私の質問は、ターミナルエミュレータがTTYよりもはるかに遅くなるのはなぜですか?TTYと同じくらい速くする可能性はありますか?ハードウェアアクセラレーションか何か?私が知っていることの1つは、最大化されたターミナルエミュレータを実行しているときのXサーバーでの解像度は1920x1080であり、TTYを実行しているときはそれよりも小さくなりますが、これがパフォーマンスにどのように影響するかわかりません。


どこかに大きなバッファがあるように聞こえます
トールビョーンラヴンアンダーセン

2
tty [1-6]は必ずしも自然に高速ではないことに注意してください。私が使用しているマシンの1つでは、xtermが適切に動作している間、テキストコンソールは非常に遅くなります。
把友情留在無盐

回答:


75

GUIターミナルエミュレーターが文字列を出力するとき、文字列をフォントコードポイントに変換し、コードポイントをフォントレンダラーに送信し、ビットマップを取得し、そのビットマップをXサーバー経由でディスプレイにブリットする必要があります。

フォントレンダラーは、グリフを取得して実行する必要があります(Truetype / Opentypeフォントは、フォントレンダラーの仮想マシン内で実行されるプログラムであることをご存知ですか?)。各グリフを実行するプロセス中に、フォントメトリック、カーニング(モノスペースフォントとカーニングはうまく混合しませんが)、Unicode準拠に関して、非常に多くの決定が行われます。 -ピクセルアドレス指定。端末は、フォントラスタライザーによって生成されたバッファーを適切な場所に移動し、ピクセル形式の変換、アルファチャネル(サブピクセルアドレス指定用)、スクロール(ブリッティングが必要)などを処理する必要あります。

それに比べて、テキストモードで実行されている仮想端末(注:グラフィカルコンソールではない)に文字列を書き込むには、その文字列をビデオメモリに書き込む必要があります。'こんにちは世界!' 13バイトの書き込みが含まれます(色が必要な場合は、16ビットワードも13個)。Xフォントラスタライザーは、まだストレッチエクササイズとナックルクラックを開始していません。これで完了です。これが、テキストモードが過去数十年で非常に重要だった理由です。それはです非常に実装するために高速。スクロールさえあなたが思っているよりも簡単です:由緒あるMotorola 6845ベースのMDAおよびCGAでさえ、レジスタに単一の8ビット値を書き込むことで画面を垂直にスクロールできました(16かもしれません...長すぎます)。画面更新回路残りをやった。基本的に、フレームバッファの開始アドレスを変更していました。

同じコンピュータ上でテキストモードの端末と同じくらい高速にグラフィカル端末を作成するためにできることは何もありません。しかし、気をつけてください:現代のコンピューターで見られる可能性のある最も遅いグラフィカル端末よりも遅いテキストモードのコンピューターがあります。元のIBM PCはかなり悪かった(DOSはソフトウェアのスクロール、ため息をついた)。80286で最初のMinixコンソールを見たとき、(ジャンプ)スクロールの速度に驚きました。進捗は良好です。

更新:ターミナルを加速する方法

@ poigeはすでに彼の答えで3つ言及していますが、ここに私自身の見解があります:

  • 端末のサイズを小さくします。私の端末は、画面がいっぱいになるまで成長する傾向があり、それを行うと遅くなります。グラフィカル端末に腹を立ててイライラし、それらのサイズを変更すると、すべてが良くなります。:)
  • (@poige)別のターミナルエミュレータを使用します。いくつかの最新機能を犠牲にして、速度を大幅に向上させることができます。xtermそしてrxvt仕事は本当によく、それは素晴らしい端末エミュレータを持っています。あなたのテストは、「最新の」テストよりもパフォーマンスが優れていることを示していると思われます。
  • (@poige)スケーラブルフォントを使用しないでください。1986年は端末を呼び出して返送するかもしれませんが、より高速であることは否定できません。;)
  • (@poige)アンチエイリアス/サブピクセルのアドレス指定とヒントをオフにすることにより、フォントラスタライザーをダンプします。それらのほとんどは環境変数のオーバーライドを許可しているため、これをグローバルに行う必要はありません。注:ビットマップフォントを選択した場合は意味がありません。
  • これは最も傷つきますtmux使用しないでください(複数のペインを使用) — 2つの別々のターミナルを並べて実行します。ときにtmux2つのペインを表示し、それはたくさんの周りにカーソルを移動するために、端末のディレクティブを使用する必要があります。最新の端末ライブラリは非常に高速で最適化に優れていますが、未処理の端末帯域幅からバイトを盗んでいます。DEC VT互換端末上の任意の行にカーソルを移動するには、を送信しますESC [ row ; col H。これは6〜10バイトです。複数の端末を使用すると、作業を分離し、ポジショニング、最適化、バッファリング、その他すべての機能を不要にcursesし、複数のCPUコアをより有効に活用できます。

5
+1。ただし、tmuxの処理は、送信される追加のエスケープコードよりもさらに複雑です。端末は、ウィンドウの半分ではなく、ウィンドウ全体をスクロールするためのものです。したがって、tmuxが左ペインのすべてのテキストを1行上に移動する必要がある場合、新しい行を作成して端末に上に移動させることはできず、ペイン全体を再描画する必要があります。
パトリック

1
まったく正しい!私はそれを忘れていました。画面の一部をスクロールできる端末がありました(IIRCは画面の「保護」部分と呼ばれていました—フォームなどに使用されていました)、特に柔軟性がなく、おそらく最新の端末エミュレーターではサポートされていません。いくつかの本当に奇妙な時代遅れのディレクティブが今日でも実装されているのを見つけたとしても。
アレクシオス

3年後にこれに返信しますが、誰かがこれが役に立つと思ってください。vimで垂直分割を行った場合(そう、NERDTreeでさえ)にのみラグに気づきますが、スクロール中に通常の分割はまったく問題にならないようです。
悲鳴を上げる

17

一方、@ Alexiosはすべての理由をかなりよく説明していますが、痛みを比較的軽減するいくつかのことを挙げることができます。

  • ビットマップフォントを使用します(TerminalTerminusこれは本当に素晴らしいものです)、
  • アンチエイリアスをオフにするか、少なくともサブピクセルレンダリングを使用しないことを検討してください。
  • KDEのターミナルを使用します— konsole

1
また、これは痛みを伴うものであり、ターミナルのサイズを小さくします(OPは1920x1200pxウィンドウを使用しています)。私大きな端末が大好きで、私のものは画面とほぼ同じ大きさになるまで成長する傾向がありますが、端末が成長するにつれて端末の速度は低下します。でもkonsole(私はこれが好きです)
アレクシオス

3
konsole遅延画面更新を行います。出力をすぐに表示するのではなく、更新を「バッチ処理」するために、出力が少し増えるのを少し待ちます。これが、OPのストレステストに完全に応答するという点で、非常にうまく機能する理由です。
ninjalj

2
ある時点でフォントのレンダリングがキャッシュされていることを確認してください。文字fを表すピクセルは、pixmapにコピーされるたびにベクトル定義から再レンダリングされるとは思わない。(新しいサイズまたは新しい角度でレンダリングする必要がない限り)。本当に素敵なビットマップフォントがいくつかあるという事実に異議を唱えません。それは、見た目だけで、必要なサイズで存在する場合に最適なオプションかもしれません。
ピーターコーデス14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.