私は最近、組み込みのgnome-terminal、aterm、xterm、wterm、rxvtまで、さまざまな端末エミュレータを試しました。私が行ったテストは次の順序で行われました。
- 2つのウィンドウでtmuxウィンドウを開く
- 左ペインには、
grep a /et/c -r単純なタスクなどの詳細で集中的なタスクが表示されます。time seq -f 'blah blah %g' 100000 - 右側のウィンドウは、100行以上のコードを持つすべてのファイルを開くための構文を開くvimウィンドウになります。
左側のウィンドウに多くの出力が印刷されると、右側のウィンドウは非常に遅く応答しないように見えます。 vimでスクロールしようとしましたが、変更に1〜2秒かかります。左ペインを押すと、CtrlC10秒以上待ってから停止します。
TTYで同じ操作を実行すると（CTRL++ ALT（F[1-6]）を押す）、これは発生せず、両方のウィンドウが非常に反応します。
アンチエイリアシングフォントのようないくつかの設定をオフにし、シェーディングをオフにし、デフォルト設定を使用し、xmonadとopenboxに変更しましたが、何も変わりませんでした。
結果は端末間で実際には異なりませんが、time seq -f 'blah blah %g' 100000特にspitted Pane tmux（または他のマルチプレクサ）を実行すると応答性が異なります。ちなみに、私はこれらすべてを最大化モードで実行しています。
私はフレームバッファターミナルについて読みましたが、それがどのように機能するのか、そしてどのように使用してターミナルエミュレータの速度を上げることができるのかわかりません。
だから私の質問は、ターミナルエミュレータがTTYよりはるかに遅いのはなぜですか？ TTYと同じくらい速くできますか？たぶんハードウェアの加速や何か？私が知っている1つの事実は、最大化されたターミナルエミュレータを実行するとXサーバーの解像度が1920x1080で、TTYを実行すると解像度がそれより低いことです。しかし、これがパフォーマンスにどのような影響を与えるかはわかりません。
答え1
GUI端末エミュレータが文字列を印刷するときは、文字列をフォントコードポイントに変換し、コードポイントをフォントレンダラーに送信してビットマップを取得する必要があります。ビットブロック転送ビットマップはXサーバーを介して表示されます。
フォントレンダラーはグリフを検索して実行する必要があります（TrueType / OpenTypeフォントはプログラムフォントレンダラーの仮想マシン内で実行していますか？ ）。各グリフが実行されると、フォントサイズ、カーニング（固定幅フォントとカーニングが混在しませんが）、Unicode準拠について多くの決定が下されます。 - ピクセルアドレス指定。その後、端末はフォントラスタライザによって生成されたバッファを取得し、対応するビットブロックを正しい位置に転送し、ピクセルフォーマット変換、アルファチャンネル（サブピクセルアドレス指定用）、スクロール（含む）を処理する必要があります。もっとブリット）など
逆に、テキストモードで実行されている仮想端末に文字列を書き込む場合（注：いいえグラフィックコンソール）には、この文字列をビデオメモリに書き込むことが含まれます。 'こんにちは！ 'には、13バイト（または色が必要な場合は13個の16ビットワード）の書き込みが含まれます。 X-Font Rasterizer ストレッチ運動と関節割れ運動を始める前に作業が完了しました。これが過去数十年の間、テキストパターンがとても重要な理由です。それ非常に迅速な実装。スクロールも思ったより簡単です。古代のMotorola 6845ベースのMDAおよびCGAでも、単一の8ビット値をレジスタに書き込むことで、画面を垂直にスクロールできます（16ビット...長すぎる場合があります）。画面を更新回路残りは完了しました。実際にフレームバッファの先頭アドレスを変更しています。
グラフィック端末をテキストモード端末と同じくらい速くすることはできません。同じコンピュータ。しかし、心配しないでください。一部のコンピュータには、最新のコンピュータで見られる最も遅いグラフィック端末よりも遅いテキストモードがあります。もともとIBM PCはかなり悪かった（DOSにはソフトウェアスクロール機能がありました）。 80286で初めてMinixコンソールを見たとき、私はスクロール（ジャンプ）のスピードがどれほど速いかを見て驚きました。進行が良いです。
アップデート：端末の速度を上げる方法
@フュージ3つが言及されました。彼の答えしかし、以下は私の意見です。
- 端末のサイズを小さくしてください。私の端末は画面がいっぱいになるまで大きくなる傾向があり、いっぱいになると速度が遅くなります。グラフィックターミナルに怒ってイライラしてサイズを変更すると、すべてが良くなります。 :)
- （@poige）他の端末エミュレータを使用してください。いくつかの最新の機能を犠牲にして膨大なスピードアップを得ることができます。
xtermそしてrxvt非常にうまく機能し、素晴らしいターミナルエミュレータがあります。私はあなたのテストが「現代的な」テストよりも優れたパフォーマンスを発揮できると思います。 - (@poige) 拡張可能なフォントを使用しないでください。1986はターミナルリターンを要求するかもしれませんが、より速いことは否定できません。 ;)
- （@poige）単純化されたフォントラスタライザーアンチエイリアシング/サブピクセルのアドレス指定とヒントをオフにします。ほとんどは環境変数のオーバーライドを許可するため、グローバルに実行する必要はありません。注：ビットマップフォントを選択した場合、これは意味がありません。
- これは最大のダメージを引き起こします。使用しないでください（複数のウィンドウ）
tmux- 2つの別々の端末を並べて実行します。 2つのウィンドウを表示するときにカーソルを移動するには、tmuxターミナルコマンドを使用する必要があります。最新の端末ライブラリですが、非常に高速で最適化は優れていますが、まだ生のエンドポイント帯域幅からバイトを盗みます。 DEC VT互換端末でカーソルを任意の行に移動するには、ESC [ row ; col H.ie 6〜10バイトを送信します。複数の端末を使用すると、タスクを分離し、位置決め、最適化、バッファリング、その他すべてのタスクを必要とせず、複数のcursesCPUコアをより活用できます。
答え2
@Alexiosはすべての理由を非常によく説明していますが、比較的痛みが少なくなるいくつかの点に言及できます。
- ビットマップフォントを使用してください（
Terminal、Terminus- 本当にクールです）。 - アンチエイリアシングをオフにするか、少なくとも検討してください。サブピクセルレンダリングなし、
- KDE端末の使用 -
konsole。
答え3
他のグラフィックターミナルエミュレータよりも速い速度を提供できる反直感的なトリック（オープン/フリータイプの代わりにビットマップフォントを使用する単純なターミナルエミュより速いのは、コードのより単純なターミナルエラーのように聞こえますが）、考えてみましたか？ KittyやAlacrittyなどのOpenGL端末エミュレータ？
彼らは、他の端末エミュレータと比較して速度を使用する主な利点の1つとして速度を宣伝します。
私はあなたがプレーンテキストモードのLinuxコンソールの速度に達すると期待しません。なぜなら、2バイト（1つは文字用で、もう1つは前景色と背景色用）を正しいメモリアドレスに入れるのは速すぎるからです。 GUI端末エミュレータに来ると、おそらく最速のオプションでしょう。