Bisakah emulator terminal secepat TTY 1-6?

59

Saya telah mencoba berbagai terminal emulator akhir-akhir ini, dari terminal gnome, aterm, xterm, wterm, hingga rxvt. Tes yang saya lakukan adalah dalam urutan ini:

Buka jendela tmux dengan 2 panel
Panel kiri akan menjadi tugas intensif-verbal seperti grep a /et/c -ratau sederhanatime seq -f 'blah blah %g' 100000
Panel kanan akan menjadi jendela vim dengan sintaks aktif, membuka file apa pun yang memiliki lebih dari> 100 baris kode.

Ketika panel kiri mencetak banyak output, panel kanan tampaknya sangat lambat dan tidak responsif, saya mencoba untuk menggulir dalam vim tetapi butuh 1-2 detik untuk itu berubah. Ketika saya mencoba menekan CtrlCpada panel kiri ia menunggu lebih dari 10 detik sebelum berhenti

Ketika saya melakukan hal yang sama di TTY (menekan CTRL+ ALT+ ( F[1-6])), itu tidak terjadi dan kedua panel sangat responsif.

Saya telah memutar beberapa konfigurasi seperti font antialias, pergantian warna, menggunakan pengaturan default, dan mengubah ke xmonad dan openbox, tetapi tidak mengubah apa pun.

Hasilnya time seq -f 'blah blah %g' 100000tidak terlalu berbeda di antara terminal-terminal ini, tetapi daya tanggapnya benar-benar berbeda terutama ketika saya menjalankan panel spitted tmux (atau multiplexer lainnya). FYI, saya menjalankan semuanya dalam mode maksimal.

Saya telah membaca tentang terminal buffered terminal tetapi tidak yakin bagaimana cara kerjanya dan bagaimana bisa digunakan untuk mempercepat emulator terminal saya.

Jadi pertanyaan saya adalah, apa yang membuat emulator terminal jauh lebih lambat daripada TTY? Apakah ada kemungkinan untuk membuatnya secepat TTY? Mungkin akselerasi perangkat keras atau semacamnya? Satu hal yang saya tahu, resolusi saya di server X ketika menjalankan emulator terminal dimaksimalkan adalah 1920x1080, dan ketika saya menjalankan TTY itu kurang dari itu, tapi saya tidak yakin bagaimana ini akan mempengaruhi kinerja.

terminal tty

— pengguna17537
sumber

Kedengarannya seperti ada penyangga besar di suatu tempat

— Thorbjørn Ravn Andersen

2

Perhatikan bahwa tty [1-6] tidak selalu cepat secara alami. Pada salah satu mesin yang saya gunakan, konsol teks sangat sangat lambat sementara xterm berkinerja baik.

— 把友情留在无盐

75

Ketika emulator terminal GUI mencetak string, itu harus mengubah string ke font codepoints, mengirim codepoints ke font renderer, mendapatkan kembali bitmap dan blit bitmap itu ke tampilan melalui server X.

Font renderer harus mengambil mesin terbang dan menjalankannya (tahukah Anda bahwa font Truetype / Opentype adalah program yang berjalan di dalam mesin virtual dalam font renderer?). Selama proses menjalankan setiap mesin terbang, sejumlah keputusan gila dibuat sehubungan dengan metrik font, kerning (meskipun font monospace dan kerning tidak tercampur dengan baik), kepatuhan Unicode, dan bahkan sebelum kita mencapai rasteriser yang mungkin menggunakan sub pengalamatan -pixel. Terminal kemudian harus mengambil buffer yang dihasilkan oleh font rasteriser dan membelahnya ke tempat yang tepat, mengurus konversi format piksel, saluran alfa (untuk pengalamatan sub-piksel), menggulir (yang melibatkan lebih banyak blitting), dan lain-lain.

Sebagai perbandingan, menulis string ke Terminal Virtual yang berjalan dalam mode teks (catatan: bukan konsol grafis) melibatkan penulisan string itu ke memori video. 'Halo Dunia!' melibatkan menulis 13 byte (13 kata 16-bit jika Anda ingin warna juga). Rasteriser font X bahkan belum memulai latihan peregangan dan penjemputan buku jari, dan kita sudah selesai. Inilah mengapa mode teks sangat penting dalam beberapa dekade terakhir. Ini sangat cepat untuk diimplementasikan. Bahkan menggulir lebih mudah daripada yang Anda pikirkan: bahkan pada MDA dan CGA berbasis Motorola 6845 yang terhormat, Anda dapat menggulir layar secara vertikal dengan menulis nilai 8-bit tunggal ke register (mungkin 16 ... sudah terlalu lama). Sirkuit penyegaran layarmelakukan sisanya. Anda pada dasarnya mengubah alamat awal buffer bingkai.

Tidak ada yang dapat Anda lakukan untuk membuat terminal grafis secepat terminal mode teks pada komputer yang sama . Tapi berhati-hatilah: ada komputer dengan mode teks lebih lambat daripada terminal grafis paling lambat yang pernah Anda lihat di komputer modern. IBM PC asli sangat buruk (DOS melakukan pengguliran perangkat lunak, desah). Ketika saya melihat konsol Minix pertama saya pada 80286, saya kagum dengan kecepatan scroll (melompat). Kemajuan itu baik.

Perbarui: cara mempercepat terminal

@ poige sudah menyebutkan tiga jawaban , tapi ini pendapat saya sendiri:

Kurangi ukuran terminal. Terminal saya sendiri cenderung tumbuh sampai mereka mengisi layar, dan mereka menjadi lambat saat mereka melakukannya. Saya jengkel, jengkel di terminal grafis, lalu saya ubah ukurannya dan semuanya lebih baik. :)
(@poige) Gunakan emulator terminal yang berbeda. Anda bisa mendapatkan peningkatan kecepatan besar dengan mengorbankan beberapa fitur modern. xtermdan rxvtbekerja dengan sangat baik, ia memiliki emulator terminal yang fantastis. Saya menduga tes Anda mungkin menunjukkan kinerjanya lebih baik daripada yang 'modern'.
(@poige) Jangan gunakan font yang skalabel. 1986 dapat menelepon dan meminta terminalnya kembali, tetapi Anda tidak dapat menyangkal bahwa mereka lebih cepat. ;)
(@poige) Bodoh rasteriser font dengan mematikan pengalamatan dan petunjuk anti-aliasing / sub-pixel. Sebagian besar dari mereka memungkinkan penggantian variabel lingkungan, sehingga Anda tidak perlu melakukan ini secara global. Catatan: tidak ada gunanya jika Anda memilih font bitmap.
Ini akan paling menyakitkan: jangan gunakan (banyak panel)tmux - jalankan dua terminal terpisah berdampingan. Saat tmuxmenampilkan dua panel, ia harus menggunakan arahan terminal untuk banyak menggerakkan kursor. Meskipun perpustakaan terminal modern sangat cepat dan bagus dalam mengoptimalkan, mereka masih mencuri byte dari bandwidth terminal mentah Anda. Untuk memindahkan kursor ke baris arbitrer pada terminal yang kompatibel dengan DEC VT, Anda mengirim ESC [ row ; col H. Itu 6–10 byte. Dengan beberapa terminal, Anda memisahkan pekerjaan, menghilangkan kebutuhan untuk penentuan posisi, optimasi, buffering dan semua hal lainnya curses, dan membuat lebih baik menggunakan beberapa core CPU.

— Alexios
sumber

5

+1, tetapi hal tmux bahkan lebih rumit dari sekadar beberapa kode pelarian tambahan yang dikirim. Terminal dimaksudkan untuk menggulir seluruh jendela, bukan setengahnya. Jadi ketika tmux harus memindahkan semua teks di panel kiri ke atas baris, itu tidak bisa hanya membuat baris baru dan membiarkan terminal memindahkannya, itu harus menggambar ulang seluruh panel.

— Patrick

1

Benar sekali! Saya lupa tentang itu. Meskipun ada telah menjadi terminal yang bisa gulir bagian dari layar (IIRC itu disebut 'melindungi' bagian dari layar - itu digunakan untuk bentuk dll), itu tidak pernah sangat fleksibel, dan mungkin tidak didukung oleh emulator terminal modern. Meskipun Anda menemukan beberapa arahan usang yang benar-benar aneh masih diterapkan hari ini.

— Alexios

Membalas ini setelah 3 tahun tetapi berharap seseorang menemukan ini berguna. Saya memperhatikan kelambatan hanya ketika saya melakukan split vertikal di vim saya (ya, bahkan NERDTree) tetapi split normal tampaknya tidak menjadi masalah sama sekali selama bergulir.

— pekik

17

Sementara @Alexios telah menggambarkan dengan baik semua alasan, saya dapat menyebutkan beberapa hal, yang relatif menghilangkan rasa sakit:

gunakan font bitmap ( Terminal, Terminus- ini benar-benar hebat),
matikan anti-aliasing, atau pertimbangkan setidaknya tidak menggunakan rendering sub-pixel ,
gunakan terminal KDE - konsole.

— poige
sumber

1

Juga, dan ini yang menyakitkan, kurangi ukuran terminal (OP menggunakan jendela 1920x1200px). Saya suka terminal besar, dan terminal saya cenderung tumbuh sampai mereka hampir sebesar layar, tetapi kecepatan terminal turun seiring terminal tumbuh. Bahkan konsole(yang saya sukai).

— Alexios

3

konsoletidak memperbarui layar malas: alih-alih segera menampilkan output, ia menunggu sedikit waktu untuk lebih banyak output, sehingga untuk "batch" pembaruan. Itulah sebabnya ia berkinerja sangat baik, sampai benar-benar responsif dengan tes stres OP.

— ninjalj

2

Cukup yakin rendering font di-cache di beberapa titik. Saya tidak berpikir piksel yang mewakili huruf f dapat dirender ulang dari definisi vektor setiap kali disalin ke sebuah pixmap. (kecuali harus dibuat pada ukuran baru, atau sudut baru). Saya tidak akan membantah fakta bahwa ada beberapa font bitmap yang sangat bagus, yang mungkin menjadi pilihan terbaik hanya untuk penampilan saja, jika mereka ada untuk ukuran yang Anda inginkan.

— Peter Cordes