Xterm.js: Terminal tidak menghasilkan warna yang sebenarnya

Tidak sabar untuk ini. Saya telah meretas hterm mencoba mendapatkan dukungan truecolor tetapi saya merasa ini adalah pilihan yang jauh lebih baik.

Menerapkan ini perlu dilakukan di sini https://github.com/sourcelair/xterm.js/blob/365a9f949cc1acfb6c4649ee1d85da3bbc60f928/src/InputHandler.ts#L1276

Bagian yang sulit adalah menentukan bagaimana kita menyimpan warna terhadap karakter dan kemudian bagaimana merendernya (mungkin atribut style sebaris). Sesuatu seperti https://github.com/sourcelair/xterm.js/pull/450 mungkin akan menyederhanakan penambahan atribut.

Saya mungkin melihatnya ketika saya punya waktu, tetapi saya tidak bisa mengatakan saya terlalu akrab dengan urutan kontrol.

Saya melihat http://invisible-island.net/xterm/ctlseqs/ctlseqs.html tetapi sepertinya tidak dapat menemukan apa pun tentang warna asli atau warna 24-bit. Apakah saya melewatkan sesuatu, atau adakah sumber daya lain yang mencakup ini?

@cnsumner xterm saat ini tidak dapat menampilkan warna asli tetapi memiliki dukungan untuk salah satu urutan pelarian yang diusulkan. Anda dapat membaca lebih lanjut tentang ini di sini: https://Gist.github.com/XVilka/8346728
BTW ini sebagian ditentukan dalam standar ECMA-48.

Kumpulkan bukti konsep yang berantakan untuk mendapatkan ide yang lebih baik tentang apa yang perlu kita lakukan di sini https://github.com/Tyriar/xterm.js/tree/484_truecolor

Hal-hal yang perlu dilakukan:

• Cabang saat ini menambahkan nomor lain ke setiap karakter yang mewakili 'warna asli' dalam format 0x1RRGGBB (fg) atau 0x0RRGGBB (bg), yang cocok dengan bilangan bulat 32 bit
• Perlu untuk mendukung kedua fg dan bg warna, dan dapat mencampur truecolor dan warna biasa
• curTrueColor sangat jelek
• Dukungan terbalik
• Bendera warna perlu dihapus saat sel digunakan kembali

• Mungkin sudah waktunya untuk memikirkan kembali bagaimana karakter dikodekan, format saat ini adalah:

  [attribute, character, width]
  

  • attribute : Sebuah bilangan bulat 32-bit yang menampung ascii fg, ascii bg dan flag (tebal, garis bawah, kedip, terbalik, tidak terlihat), tidak semua bit digunakan
  • char : Baik string kosong (untuk 0 karakter lebar yang mengisi karakter lebar) atau string unicode karakter tunggal
  • width : Lebar char, saat ini bisa 0, 1 atau 2 tetapi ini bisa mencakup lebih banyak untuk mendukung tab dengan benar https://github.com/sourcelair/xterm.js/issues/734
• Solusi akhirnya harus ringkas untuk memori dan juga cepat untuk diakses, tetap menggunakan array, flag biner, dan pergeseran bit untuk data mungkin adalah ide terbaik.

@Tyriar
Ya penggunaan memori akan meledak jika tidak dioptimalkan untuk konsumsi rendah. Mungkin dapat dikemas bersama dengan width , bidang ini tidak mungkin menjadi lebih besar dari 16 dengan hanya memakan 4 byte (default tab ke 4 atau 8 secara normal). Ini menyisakan ruang untuk satu definisi RGB* (dengan asumsi width adalah bilangan bulat 32bit). Tidak yakin berapa banyak bit yang gratis di attribute , mungkin ada definisi RGB kedua .

Sepertinya atribut saat ini menggunakan 9 byte untuk bg, 9 byte untuk bg dan 5 byte untuk flag, menyisakan banyak lebar untuk diperas di bagian akhir. Definisi RGB masing-masing membutuhkan 24 byte (8*3).

Inilah pendekatan penghematan ruang (sedikit rumit) yang saya pikir Anda sarankan:

[char, attr1, attr2]

Di mana attr1 adalah (29 bit):

• lebar: 4 bit
• adalah 256 warna atau bendera truecolor: 1 bit
• bg warna: 24 bit

Dan attr2 adalah (30 bit):

• bendera: 5 bit
• adalah 256 warna atau bendera truecolor: 1 bit
• warna fg: 24 bit

Pendekatan yang lebih sederhana akan menggunakan angka khusus untuk atribut:

[char, attr, truecolorBg, truecolorFg]

Dimana attr adalah:

• lebar: 4 byte
• bendera: 5 byte
• 256 bg warna: 9 byte
• 256 fg warna: 9 byte

Saya sangat ingin merangkum detail ini karena mereka benar-benar memperumit masalah, saya bertanya-tanya apakah TypeScript akan membiarkan kita menempatkan getter pada array entah bagaimana. Menggunakan objek 20x lebih lambat daripada array berdasarkan benchmark mikro yang saya lakukan di jsperf, saya tahu mereka tidak selalu dapat diandalkan tetapi ini adalah jenis yang saya harapkan sebagai overhead untuk membuat objek berdasarkan prototipe.

Apa pun yang kami lakukan, formatnya perlu didokumentasikan dengan sangat baik. Saat ini Anda harus mencari tahu sendiri dengan melihat InputHandler.charAttributes .

Beberapa pemikiran lagi tentang penghematan memori:

• Jika sebuah karakter memiliki lebar > 1, kita sebenarnya tidak perlu menyimpan data sama sekali untuk karakter berikut. "Karakter kosong" ada sebagai solusi dan mungkin akan berfungsi dengan baik menjadi null .
• Biasanya satu set karakter ditata, yang berarti atribut dapat dibagi di antara urutan karakter.
• Atribut dapat di-cache dan setiap karakter menggunakan pointer ke salah satu nilai yang di-cache,

Ya, saya pikir pada sebagian besar mesin JS, array dengan akses indeks masih lebih cepat daripada objek dan penyelesaian propertinya. V8 mendapat beberapa optimasi ekstra untuk objek. Konstruksi dan GC dari segi array lebih cepat karena tata letak memori yang lebih sederhana (kerugian ini dapat dihilangkan dengan menggunakan kembali objek yang ada).

Saya tidak tahu tentang tata letak yang tepat di sini, masalahnya adalah bahwa setiap barang yang dikemas dengan baik akan meningkatkan hukuman runtime karena transformasi yang diperlukan. (Ini adalah salah satu alasan untuk tidak menggunakan bitfield di C jika memori tidak menjadi perhatian - operasi shift yang diperlukan akan mencemari cache instruksi yang menyebabkan cache hilang - kode berjalan jauh lebih lambat).
Imho hanya tes yang akan menunjukkan apa yang paling berhasil di sini.

@jerch menarik, saya memiliki 4 versi nomor untuk kesederhanaan sekarang di https://github.com/sourcelair/xterm.js/pull/756.

Jadi memori di sini diharapkan sekitar: 5 * (1000 scrollback) * (8 byte pada mesin 64-bit) * 80 = 3,2mb (sebelum overhead array js). Lebar sebenarnya dari terminal Kode VS biasa akan terlihat dua kali lipat jika kita mempertahankan format saat ini. Tampaknya cukup curam sekarang setelah saya melihatnya, terutama karena pengguna sering kali memiliki lebih dari 1000 scrollback dan beberapa terminal aktif. Spasi tambahan yang benar-benar tidak menambah banyak sama sekali dan bisa dengan mudah menjadi nol yang mungkin akan menjadi kemenangan yang cukup besar.

Ide cache set atribut/warna juga tampaknya menjanjikan, selama ada cara yang baik untuk akses cepat. Struktur seperti pohon splay ringan akan ideal (akses cepat untuk atribut yang paling sering digunakan).

Mungkin juga layak untuk melihat penggunaan kembali array data baris saat dipangkas alih-alih hanya membuangnya ( mis. di sini ).

Ya dan dengan mesin overhead dalam pikiran itu tumbuh lebih besar - segala sesuatu dalam array atau objek disimpan sebagai referensi, pada dasarnya pointer ke konten. Js-array padat memiliki sedikit keuntungan di sini, mereka dibentuk sebagai array seperti C di suatu tempat di jalan (sebenarnya ArrayLists). Array jarang dan objek lain dibangun dengan beberapa keajaiban pohon untuk menyelesaikan resolusi properti.
Jadi untuk 64bit, referensi menambahkan 5 * 8 byte lebih banyak per sel (pada dasarnya menggandakan perhitungan Anda di atas - 6.4mb). Konten dapat menambahkan lebih banyak byte di samping "konten nyata", tetapi ini tergantung pada implementasi aktual dari tipe Integer dan String.

Mungkin TypedArray dapat menyelesaikan ini. Di sana barang-barang integer dapat berada langsung di posisi indeks dalam memori tanpa tipuan tambahan. asm.js pada dasarnya hanya beroperasi pada itu.

Berikut adalah tolok ukur mikro cepat untuk membandingkan TypedArray dan js-Array untuk pembuatan dan penyisipan data: http://jsbench.github.io/#af3ea1056a70df2aa6775699d174df0d

TypedArray berjalan 10 kali lebih cepat dengan FF dan Chrome di mesin saya. Ini mungkin karena alokasi awal, belum menguji ini dengan js-Array karena tidak disarankan. Tidak yakin apakah JIT melihat fakta, bahwa nilainya hanya meningkat 1 setiap 8 byte dan bahkan mengoptimalkannya. Maka benchmark tidak berguna sama sekali.

Aksesnya sedikit lebih buruk untuk TypedArray (mungkin karena konversi Number ), konsumsi memori jauh lebih baik dengan TypedArray.

Kelemahan dari TypedArray adalah blok statis memori ketika datang ke data cadangan (trik untuk menghindari data sama sekali tidak akan berfungsi di sini, memori "hilang") atau mengubah ukuran dengan pembungkusan konten. Sulit untuk melakukannya dengan benar dan cenderung melibatkan penyalinan data dalam jumlah besar berulang-ulang.

Halo. Ada pembaruan tentang ini? Tidak sabar untuk membuat ini berfungsi

Apakah ada yang secara aktif menangani masalah ini? Apakah sedang dibahas di tempat lain? @chabou @Tyriar? Apakah Microsoft membantu mengingat penggunaan dalam VS Code?

Ini adalah masalah lagging terakhir untuk menggunakan hyper di WSL pada Windows 10 untuk menyediakan alur kerja dev CLI yang mendukung tmux dan vim/neovim. Emulator terminal lain yang tersedia untuk digunakan dengan WSL tidak menyenangkan untuk dilihat, wsltty sudah dekat, tetapi dukungan tab dan dukungan plugin tidak ada...

@vastbinderj Mengapa dukungan warna asli yang hilang tidak memberi Anda alur kerja dev CLI yang layak? Pertanyaan jujur.

@szmarczak dan @vastbinderj
Masalah ini masih dalam agenda, tetapi agak diblokir karena penggunaan memori yang tinggi akan diperkenalkan dengan desain buffer terminal saat ini. Ini akan mendapatkan lebih banyak perhatian ketika #791 telah memberi kita tata letak buffer yang lebih efisien.

@rfgamaral simple - Saya bekerja di banyak server unix/linux yang berbeda setiap hari pada sistem perusahaan yang sangat besar dengan banyak layanan mikro dan tidak memiliki dukungan warna yang layak di Host utama mengganggu. Untuk menangani warna yang tidak sama apakah saya menggunakan rhel atau centos atau debian, itu menyakitkan. Juga, duduk untuk membantu pengembang jr atau rekan di windows berarti saya harus beralih konteks jika semuanya tidak berfungsi secara seragam. Namun, saya sangat terkesan seberapa jauh wsl telah datang begitu cepat dengan peningkatan yang dirilis hampir setiap bulan dan sama dengan VS Code, ini luar biasa.

@jerch Terima kasih atas pembaruannya, akan menunggu dengan sabar untuk #791 untuk dikerjakan ...

Sangat menantikan ini juga.

Perlu diingat bahwa angka JavaScript dapat mewakili bilangan bulat yang tepat hingga 53 bit. Jadi Anda memiliki 21 bit selain 32 bit "nyaman". Anda dapat "atau" sedikit dengan tambahan sederhana, jika belum disetel. Untuk membaca bit orde tinggi, cukup bagi dengan bilangan bulat pangkat dua yang sesuai, dan kemudian gunakan operasi bit biasa.

Tentu saja ada sedikit lebih banyak overhead yang bekerja dengan bit orde tinggi, tetapi pada CPU modern pembagian dengan daya-atau-dua relatif murah - lebih murah daripada akses memori.

Saya sarankan menggunakan satu nomor dengan 50 bit: masing-masing 25 bit untuk latar depan dan latar belakang. Satu bit jika disetel menunjukkan bahwa kami menggunakan warna "benar" 24-bit; jika tidak disetel, kami menggunakan warna "logis" (bertema) atau 8-bit. Bit indikator harus menjadi 2 bit orde rendah; jika tidak disetel warna logis/8-bit bisa ada di 30 bit berikutnya, jadi kami hanya menggunakan bit 32-50 jika kami benar-benar menggunakan warna asli.

@PerBothner Kami memutuskan untuk menggunakan Uint32Array untuk buffer baru, dan untuk kenyamanan memasukkan warna ke dalam array itu juga. Ini belum selesai karena kami ingin membersihkan impl baru terlebih dahulu sebelum mendukung truecolor.

Saya juga melakukan beberapa tes/perhitungan tentang kemungkinan tata letak (lihat https://Gist.github.com/jerch/27c2cf91ad313a25415873e4047b2900). Singkat cerita - idenya adalah tentang penghematan mem tradeoff vs penalti runtime. Transisi ke array yang diketik sudah memberikan penghematan mem besar (saat ini mengimplementasikan ide kedua dari atas, meskipun nilai warna sebenarnya belum diterapkan).