端末エミュレータはTTY 1〜6の速度で動作できますか？
最近、組み込みのgnomeターミナル、aterm、xterm、wtermからrxvtまで、さまざまなターミナルエミュレータを試しています。私が行ってきたテストはこの順序です：
- 2つのペインを持つtmuxウィンドウを開く
- 左側のペインは、
grep a /et/c -rまたは単純なtime seq -f 'blah blah %g' 100000などの冗長なタスクになります - 右側のペインは構文がオンのvimウィンドウで、コードが100行を超えるファイルを開きます。
左側のペインが大量の出力を印刷しているときに、右側のペインが非常に遅く応答がないように見えるので、vimでスクロールしようとしましたが、変更に1〜2秒かかります。押してみると CtrlC 左側のペインでは、停止する前に10秒以上待機します
TTYで同じことをすると（ CTRL+ALT+（F[1-6]））、それは起こりません、そして両方のペインは非常に反応します。
アンチエイリアスフォント、カラーリング、デフォルト設定の使用、xmonadとopenboxへの変更など、いくつかの設定を無効にしましたが、何も変更しません。
time seq -f 'blah blah %g' 100000の結果はこれらの端末間で実際には異なりませんが、特にスピットドペインtmux（または他のマルチプレクサ）を実行している場合、応答性は実際には異なります。参考までに、すべてを最大化モードで実行しています。
フレームバッファリングされたターミナルについて読みましたが、それがどのように機能し、ターミナルエミュレータを高速化するためにどのように使用できるのかはわかりません。
だから私の質問は、ターミナルエミュレータがTTYよりもはるかに遅くなるのはなぜですか？ TTYと同じくらい速くする可能性はありますか？多分ハードウェアアクセラレーションか何か。私が知っていることの1つは、最大化されたターミナルエミュレーターを実行しているときのXサーバーの解像度が1920x1080であり、TTYを実行しているときはそれよりも小さいですが、これがパフォーマンスにどのように影響するかはわかりません。
GUIターミナルエミュレータが文字列を出力するとき、文字列をフォントコードポイントに変換し、コードポイントをフォントレンダラーに送信し、ビットマップと blit XビットマップをXサーバー経由でディスプレイに返す必要があります。 。
フォントレンダラーは、グリフを取得して実行する必要があります（Truetype/Opentypeフォントはprogramsフォントレンダラーで仮想マシン内で実行されていることをご存知でしたか？）。各グリフを実行するプロセス中に、フォントメトリック、カーニング（モノスペースフォントとカーニングはうまく混ざりませんが）、Unicode準拠に関して非常に多くの決定が行われます。 -ピクセルアドレッシング。次に、ターミナルは、フォントラスタライザーによって生成されたバッファーを取得し、適切な場所にブリットし、ピクセル形式の変換、アルファチャネル（サブピクセルアドレス指定用）、スクロール（-moreブリッティング）、など。
対照的に、テキストモードで実行されている仮想ターミナルに文字列を書き込む（注：notグラフィカルコンソール）には、その文字列をビデオメモリに書き込む必要があります。 「こんにちは、世界！」は13バイトの書き込みを含みます（色も必要な場合は、13ビットの16ビットワードも）。 Xフォントラスタライザは、まだストレッチングエクササイズとナックルクラッキングをまだ開始していません。これで完了です。これが、テキストモードが過去数十年で非常に重要になった理由です。 very実装は高速です。スクロールすら想像以上に簡単です。由緒あるMotorola 6845ベースのMDAとCGAでも、単一の8ビット値をレジスターに書き込むことで画面を垂直方向にスクロールできます（16になる可能性があります...は長すぎます）。画面の更新回路は残りを行いました。フレームバッファーの開始アドレスを本質的に変更していました。
sameコンピュータ上で、グラフィカル端末をテキストモード端末と同じくらい高速にする方法はありません。しかし、心に留めてください。最近のコンピューターで見られる可能性が最も遅いグラフィカル端末よりもテキストモードが遅いコンピューターが存在します。元のIBM PCはかなり悪かった（DOSはソフトウェアのスクロールを行った、ため息）。 80286で最初のMinixコンソールを目にしたとき、（ジャンプ）スクロールの速度に驚きました。進捗状況は良好です。
更新：端末を高速化する方法
@ poige はすでに 彼の答え で3つ言及していますが、ここでは私自身の見解を示します。
- 端末のサイズを小さくします。私自身の端末は、画面いっぱいになるまで大きくなる傾向があり、そのようにすると遅くなります。私は激怒し、グラフィカル端末に悩まされてから、それらのサイズを変更します。 :)
- （@ poige）別のターミナルエミュレータを使用します。いくつかの最新の機能を犠牲にして、速度を大幅に向上させることができます。
xtermとrxvtは非常にうまく機能し、素晴らしい端末エミュレーターを備えています。あなたのテストでは、「モダン」テストよりもパフォーマンスが高いことが示されているのではないかと思います。 - （@ poige）スケーラブルフォントを使用しないでください。1986は、その端末を呼び出して要求する場合がありますが、高速であることを否定することはできません。 ;）
- （@ poige）アンチエイリアス/サブピクセルのアドレス指定とヒントをオフにして、フォントラスタライザを調整します。それらのほとんどは環境変数のオーバーライドを許可しているため、これをグローバルに行う必要はありません。注：ビットマップフォントを選択しても意味がありません。
- これは最も害を及ぼします：使用しないでください（複数のペインで）
tmux— 2つの個別の端末を並べて実行します。tmuxが2つのペインを表示する場合、ターミナルディレクティブを使用してカーソルをたくさん移動する必要があります。最近の端末ライブラリはvery高速で最適化に優れていますが、端末の未処理の帯域幅からバイトを盗んでいます。 DEC VT互換端末の任意の行にカーソルを移動するには、ESC [ row ; col Hを送信します。これは6〜10バイトです。複数の端末を使用すると、作業を分離し、配置、最適化、バッファリングなど、cursesが行うすべてのことを行う必要がなくなり、複数のCPUコアをより効率的に使用できます。
一方、@ Alexiosはすべての理由をかなりよく説明してきましたが、いくつかのことを述べておくと、比較的痛みが軽減されます。
- ビットマップフォントを使用（
Terminal、Terminus—これは本当に素晴らしいフォントです）、 - アンチエイリアスをオフにするか、少なくとも サブピクセルレンダリングを使用しない を検討してください。
- kDEのターミナル—
konsoleを使用します。