Xterm.js: ターミナルはトゥルーカラーをレンダリングしません

これが待ちきれません。 私はトゥルーカラーのサポートを得るためにハイパーターミナルをハッキングしてきましたが、これははるかに優れたオプションだと思います。

これを実装するには、ここで行う必要がありますhttps://github.com/sourcelair/xterm.js/blob/365a9f949cc1acfb6c4649ee1d85da3bbc60f928/src/InputHandler.ts#L1276

トリッキーな部分は、文字に対して色を保存する方法と、それをレンダリングする方法（おそらくインラインstyle属性）を決定することです。 https://github.com/sourcelair/xterm.js/pull/450のようなものは、おそらく属性の追加を単純化するでしょう。

時間があれば見てみるかもしれませんが、制御シーケンスに精通しているとは言えません。

http://invisible-island.net/xterm/ctlseqs/ctlseqs.htmlを調べましたが、トゥルーカラーまたは24ビットカラーについては何も見つかりませんでした。 私は何かが足りないのですか、それともこれをカバーする他のリソースがありますか？

@cnsumner xtermは現在、トゥルーカラーを表示できhttps ：
ところで、これはECMA-48標準で部分的に指定されています。

ここで何をする必要があるかをよりよく理解するために、厄介な概念実証をまとめてくださいhttps://github.com/Tyriar/xterm.js/tree/484_truecolor

実行する必要があること：

• ブランチは現在、32ビット整数に収まる0x1RRGGBB （fg）または0x0RRGGBB （bg）の形式で「truecolor」を表す各文字に別の数値を追加します
• fgとbgの両方の色をサポートし
• curTrueColorはとても醜いです
• 逆をサポート
• セルを再利用する場合は、カラーフラグをクリアする必要があります

• 文字がどのようにエンコードされているかを再考する時期かもしれません。現在の形式は次のとおりです。

  [attribute, character, width]
  

  • attribute ：ascii fg、ascii bg、およびフラグ（太字、下線、点滅、反転、非表示）を保持する32ビット整数。すべてのビットが使用されるわけではありません。
  • char ：空の文字列（ワイド文字を埋める0幅の文字の場合）または1文字のUnicode文字列
  • width ：文字の幅は現在0、1、または2ですが、タブを適切にサポートするためにさらに多くの文字を含めることができますhttps://github.com/sourcelair/xterm.js/issues/734
• 最終的なソリューションは、メモリに対してコンパクトであり、アクセスも迅速である必要があります。配列、バイナリフラグ、およびデータのビットシフトを使用するのがおそらく最良のアイデアです。

@Tyriar
ええ、それが低消費のために最適化されていない場合、メモリ使用量は爆発します。 widthと一緒にパックできるかもしれませんが、このフィールドが16より大きくなる可能性は低く、4バイトしか消費しません（タブのデフォルトは通常4または8です）。 これにより、1つのRGB定義*の余地が残ります（ widthが32ビット整数であると想定）。 attributeで空きビット数がわからない場合は、2番目のRGB定義に進むことができます。

属性は現在、bgに9バイト、bgに9バイト、フラグに5バイトを消費しているように見え、最後に幅を絞るのに十分な余地があります。 RGB定義には、それぞれ24バイト（8 * 3）が必要です。

これが（少し複雑な）省スペースのアプローチです。あなたが提案していると思います。

[char, attr1, attr2]

attr1は（29ビット）です。

• 幅：4ビット
• 256色またはトゥルーカラーフラグ：1ビット
• bgカラー：24ビット

そしてattr2は（30ビット）です：

• フラグ：5ビット
• 256色またはトゥルーカラーフラグ：1ビット
• fgカラー：24ビット

より単純なアプローチでは、特に属性に番号を使用します。

[char, attr, truecolorBg, truecolorFg]

attrは次のとおりです。

• 幅：4バイト
• フラグ：5バイト
• 256 bgカラー：9バイト
• 256 fgカラー：9バイト

これらの詳細は本当に複雑なので、ひどくカプセル化したいのですが、typescriptを使用すると、ゲッターを配列に配置できるのではないかと思います。 オブジェクトの使用は、jsperfで行ったマイクロベンチマークに基づく配列よりも20倍遅く、常に信頼できるとは限りませんが、これは、プロトタイプに基づいてオブジェクトを作成するためのオーバーヘッドとして期待したものです。

何をするにしても、フォーマットは非常によく文書化する必要があります。 今、あなたはInputHandler.charAttributes見て自分でそれを理解する必要があります。

メモリ節約に関するもう少しの考え：

• 文字の幅が1より大きい場合、次の文字のデータを保存する必要はまったくありません。 「空の文字」は回避策としてあり、 nullあれば問題なく動作する可能性があります。
• 通常、文字のセットはスタイル設定されます。つまり、属性は文字のシーケンス間で共有できます。
• 属性はキャッシュされる可能性があり、各文字はキャッシュされた値の1つへのポインターを使用します。

はい、ほとんどのJSエンジンでは、インデックスにアクセスできる配列は、オブジェクトとそのプロパティの解決よりも高速であると思います。 ただし、V8ではオブジェクトに対していくつかの追加の最適化が行われました。 構築とGCに関しては、メモリレイアウトがはるかに単純なため、配列の方が高速です（この欠点は、既存のオブジェクトを再利用することで省略できます）。

ここで正しいレイアウトについての手がかりはありません。問題は、密集したものがあると、必要な変換のために実行時のペナルティが発生することです。 （これは、メモリが問題にならない場合にCでビットフィールドを使用しない理由の1つです。必要なシフト操作によって命令キャッシュが汚染され、キャッシュミスが発生します。コードの実行速度が大幅に低下します）。
Imhoのみのテストでは、ここで最も効果的なものが示されます。

@jerch興味深いですが、 わかりやすくするために4つの番号バージョンがあります。

したがって、ここでのメモリは約5 *（1000スクロールバック）*（64ビットマシンでは8バイト）* 80 = 3.2mb（js配列のオーバーヘッド前）であると予想されます。 現在のフォーマットを維持すると、一般的なVSCode端末の実際の幅は2倍になります。 私がそれを見ると、特にユーザーが1000を超えるスクロールバックと複数のアクティブな端末を持っていることが多いため、かなり急なようです。 末尾の空白は実際にはほとんど追加されず、同じように簡単にnullになる可能性があり、おそらくかなり大きな勝利になります。

高速アクセスのための良い方法がある限り、属性/カラーセットキャッシュのアイデアも有望であるように思われます。 軽量のスプレーツリーのような構造が理想的です（属性への高速アクセスが最も頻繁に使用されます）。

また、ラインデータ配列を単に破棄するのではなく、トリミングしたときに再利用することを検討する価値があるかもしれません（例：ここ）。

ええ、エンジンのオーバーヘッドを念頭に置いて、それはさらに大きくなります-配列またはオブジェクト内のすべてが参照として保存され、基本的にはコンテンツへのポインターです。 密なjs配列には、ここでわずかな利点があります。パスのどこかでCのような配列として形成されます（実際にはArrayLists）。 スパース配列およびその他のオブジェクトは、プロパティの解決を解決するためにいくつかのツリーマジックを使用して構築されます。
したがって、64ビットの場合、参照対象はセルごとに5 * 8バイトを追加します（基本的に、上記の計算は2倍になります-6.4mb）。 コンテンツは「実際のコンテンツ」の横にさらにバイトを追加できますが、これは整数型と文字列型の実際の実装によって異なります。

TypedArrayでこれを解決できるかもしれません。 そこでは、整数のものは、追加の間接参照なしで、メモリ内のインデックス位置に直接存在できます。 asm.jsは基本的にそれらに対してのみ動作します。

ここで作成し、データ挿入のためTypedArrayとJS-配列を比較するための迅速なマイクロベンチマークは次のとおりです。 http://jsbench.github.io/#af3ea1056a70df2aa6775699d174df0d

TypedArrayは、私のマシンでFFとChromeを使用すると10倍高速に実行されます。 これは事前割り当てが原因である可能性があります。推奨されていないため、js-Arrayでこれをテストしていません。 JITが事実を発見したかどうかはわかりませんが、値は8バイトごとに1ずつ増加し、これを最適化することさえあります。 そうすると、ベンチマークはまったく役に立たなくなります。

TypedArrayのアクセスはわずかに悪く（おそらくNumber変換のため）、TypedArrayを使用するとメモリ消費がはるかに良くなります。

TypedArrayの欠点は、スペアデータ（データを回避するためのトリックはここでは機能せず、メモリはとにかく「失われる」）またはコンテンツの折り返しによるサイズ変更の場合のメモリの静的ブロックです。 それを正しく行うのは難しく、大量のデータを何度もコピーする必要があります。

こんにちは。 これに関する更新はありますか？ これが機能するのを待つことはできません😃

この問題に積極的に取り組んでいる人はいますか？ それは他のどこかで議論されていますか？ @chabou @Tyriar？ マイクロソフトはVSCodeでの使用法を考慮して支援していますか？

これは、Windows 10のWSLでhyperを使用して、tmuxとvim / neovimをサポートする適切な開発CLIワークフローを提供するための最後の遅れている問題です。 WSLで使用できる他のターミナルエミュレーターは見た目が良くなく、wslttyは近いですが、タブのサポートとプラグインのサポートがありません...

@vastbinderj不足しているトゥルーカラーのサポートが適切な

@szmarczakと@vastbinderj
この問題はまだ議題になっていますが、現在のターミナルバッファの設計で導入されるメモリ使用量が多いため、ややブロックされています。 ＃791がより効率的なバッファレイアウトをもたらしたとき、それはより注目を集めるでしょう。

@ rfgamaralsimple-私は多くのマイクロサービスを備えた非常に大規模なエンタープライズシステムで1日に多くの異なるunix / linuxサーバーで作業しており、メインホストで適切なカラーサポートがないことは混乱を招きます。 私がrhel、centos、debianのいずれを使用していても、色が同じでないことに対処するのは苦痛です。 また、Windowsでジュニアまたはピア開発者を支援するために座っているということは、物事が均一に機能しない場合はコンテキストを切り替える必要があることを意味します。 しかし、ほぼ毎月リリースされる改善とVS Codeと同じように、wslがこれほど迅速にリリースされたことに、私は非常に感銘を受けました。それは傑出しています。

@jerchアップデートをありがとう、＃791が解決されるのを辛抱強く待ちます...

これも大いに楽しみにしています。

JavaScriptの数値は、最大53ビットの正確な整数を表すことができることを覚えておく価値があります。 したがって、32個の「便利な」ビットに加えて21個のビットがあります。 まだ設定されていない場合は、単純な加算で少し「または」することができます。 上位ビットを読み取るには、適切な2の累乗の整数で除算してから、通常のビット演算を使用します。

もちろん、高次ビットを処理するオーバーヘッドは少し多くなりますが、最近のCPUでは、1または2の累乗による除算は比較的安価であり、メモリアクセスよりも安価です。

50ビットの単一の数値を使用することをお勧めします。フォアグラウンドとバックグラウンドにそれぞれ25ビットです。 セットされている場合は1ビットは、24ビットの「トゥルー」カラーを使用していることを示します。 設定されていない場合は、「論理」（テーマ可能）または8ビットカラーを使用します。 インジケータビットは下位2ビットである必要があります。 設定を解除すると、論理8ビットカラーが次の30ビットになる可能性があるため、実際にトゥルーカラーを使用している場合はビット32〜50のみを使用します。

@PerBothner新しいバッファに

また、可能なレイアウトについていくつかのテスト/計算を行いました（https://gist.github.com/jerch/27c2cf91ad313a25415873e4047b2900を参照）。 簡単に言えば、アイデアは、memの節約と実行時のペナルティのトレードオフに関するものです。 型付き配列への移行により、すでに大幅なメモリ節約が実現しました（現在、実際の色の値はまだ適用されていませんが、上記の2番目のアイデアを実装しています）。