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

最近、組み込みの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を実行しているときはそれよりも小さくなりますが、これがパフォーマンスにどのように影響するかわかりません。

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コアをより有効に活用できます。

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

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