Bir terminal emülatörü TTY 1-6 kadar hızlı olabilir mi?


59

Son zamanlarda yerleşik gnome-terminalinden, aterm, xterm, wterm'den rxvt'a kadar çeşitli terminal emülatörlerini deniyorum. Yaptığım test şu sırada:

  1. 2 bölmeli bir tmux penceresi açın
  2. Sol bölme gibi grep a /et/c -rbasit veya yoğun bir görev olacaktime seq -f 'blah blah %g' 100000
  3. Sağ bölme,> 100'den fazla kod satırı içeren herhangi bir dosyayı açarak, sözdizimi açık olan bir vim penceresi olacaktır.

Sol bölme çok fazla çıktı yazdırırken, sağ bölme çok yavaş ve tepkisiz görünüyor, vim içinde kaydırmaya çalıştım ancak değişmesi 1-2 saniye sürüyor. Ben basın çalıştığınızda CtrlCdurdu önce 10'dan fazla saniyeden bekler sol bölmedeki

Aynı şeyi TTY'de yaptığımda ( CTRL+ ALT+ ( F[1-6]) tuşlarına basıldığında ), bu gerçekleşmiyor ve her iki bölme de çok duyarlı.

Antialias fontları, renk açma, varsayılan ayarları kullanma ve xmonad ve openbox gibi bazı yapılandırmalardan vazgeçtim, ancak hiçbir şeyi değiştirmiyor.

Bunun sonucu, time seq -f 'blah blah %g' 100000bu terminaller arasında gerçekten farklı değil, ancak yanıtlılık özellikle tükürük camlı tmux (veya diğer çoklayıcılar) çalıştırdığımda gerçekten farklı. Bilginize, hepsini maksimize edilmiş bir modda çalıştırıyorum.

Çerçeve tamponlu terminalleri okudum ama nasıl çalıştığından ve terminal emülatörümü hızlandırmak için nasıl kullanılacağından emin değilim.

Öyleyse sorum şu, terminal emülatörünü TTY'den çok daha yavaş yapan nedir? TTY kadar hızlı hale getirme olasılığı var mı? Belki donanım hızlandırma ya da bir şey? Bildiğim bir şey, maksimize edilmiş bir terminal emülatörü çalıştırırken X sunucusundaki çözünürlüğüm 1920x1080'dir ve TTY'yi çalıştırdığımda bundan daha az, ancak bunun performansı nasıl etkileyeceğinden emin değilim.


Bir yerde büyük bir tampon var gibi geliyor
Thorbjørn Ravn Andersen

2
Dikkat [1-6] her zaman doğal olarak hızlı değildir . Kullandığım makinelerden birinde, xterm düzgünce çalışırken metin konsolu çok yavaş.
盐 友情 留 在 无 盐

Yanıtlar:


75

Ne zaman bir GUI terminal emülatörü basacak bir dize, o bir yazı Oluşturucuya codepoints göndermek, codepoints yazı tipi bir bit eşlem ve geri almak için dizeyi dönüştürmek için vardır blit X sunucusu üzerinden ekrana bitmap.

Yazı tipi oluşturucunun glifleri alması ve bunları çalıştırması gerekir (Truetype / Opentype yazı tiplerinin , yazı tipi oluşturucusunda sanal bir makine içinde çalışan programlar olduğunu biliyor muydunuz ?). Her glifin çalıştırılması sürecinde font ölçümleri, karakter aralığı (monospace fontları ve karakter aralığı iyi karışmasa da), Unicode uyumluluğu ile ilgili olarak çok sayıda karar verilir. -piksel adresleme. Terminal daha sonra font rasterleştiricisi tarafından üretilen tamponu almak ve piksel biçimindeki dönüşümlere, alfa kanallarına (alt piksel adresleme için), kaydırmaya ( daha fazla karıştırma içeren ), vb.

Buna karşılık, metin modunda çalışan bir Sanal Terminale bir dize yazmak (not: grafik bir konsol değil ) bu dizeyi video belleğine yazmayı içerir. 'Selam Dünya!' 13 bayt yazmayı içerir (eğer renkleri istiyorsanız, 13 16 bit kelime). X yazı tipi rasterleştiricisi germe egzersizlerine ve budak kırma çatlamalarına henüz başlamadı ve işimiz bitti. Bu nedenle, metin kipinin geçmiş yıllarda inanılmaz derecede önemli olmasının nedeni budur. Uygulaması çok hızlı. Kaydırma bile düşündüğünüzden daha kolaydır: saygıdeğer Motorola 6845 tabanlı MDA ve CGA'da bile, bir kayıt cihazına 8 bitlik tek bir değer yazarak ekranı dikey olarak kaydırabilirsiniz (16 ... çok uzun olabilir). Ekran yenileme devresiGerisini yaptım. Temel olarak çerçeve tamponunun başlangıç ​​adresini değiştiriyordunuz.

Grafiksel bir terminali aynı bilgisayardaki bir metin modu terminali kadar hızlı yapmak için yapabileceğiniz hiçbir şey yok . Ancak yürekten isteyin: Modern bir bilgisayarda görebileceğiniz en yavaş grafik terminalden daha yavaş metin modlarına sahip bilgisayarlar var. Orijinal IBM PC oldukça kötüydü (DOS yazılım kaydırma yaptı, iç çekiyordu). İlk Minix konsolumu bir 80286'da gördüğümde, (atlama) kaydırma hızına hayran kaldım. İlerleme iyi.

Güncelleme: terminal nasıl hızlandırılır

@ Poige zaten üç tane sözü var onun cevabı , ama burada benim kendi almak onlara var:

  • Terminalin boyutunu azaltın. Kendi terminallerim ekranları dolduruncaya kadar büyürler ve bunu yaptıkça yavaşlarlar. Çok yoruldum, grafiksel uçbirimde sinirleniyorum, sonra onları yeniden boyutlandırıyorum ve her şey daha iyi. :)
  • (@poige) Farklı bir terminal emülatörü kullanın. Bazı modern özelliklerin maliyeti ile büyük bir hız artışı elde edebilirsiniz. xtermve rxvtgerçekten iyi çalışır, harika bir terminal emülatörüne sahiptir. Testlerinizin 'modern' testlerden daha iyi performans gösterdiğini göstermiş olabileceğinden şüpheleniyorum.
  • (@poige) Ölçeklenebilir yazı tipleri kullanmayın. 1986, arayabilir ve terminallerini geri isteyebilir, ancak daha hızlı olduklarını inkar edemezsiniz. ;)
  • (@poige) Kenar yumuşatma / alt piksel adresleme ve ipucunu kapatarak font rasterleştiriciyi aşağı çekin . Çoğu, ortam değişkenlerinde geçersiz kılmaya izin verir, bu nedenle bunu genel olarak yapmak zorunda değilsiniz. Not: Bir bitmap fontu seçtiyseniz anlamsız.
  • Bu en çok acı verecek: kullanmayın (çoklu bölmeler)tmux - iki ayrı terminali yan yana çalıştırın. Ne zaman tmuxiki bölme görüntüler, bir sürü etrafında imleci hareket ettirmek için, terminal direktifleri kullanmak zorundadır. Modern terminal kütüphaneleri optimizasyonda çok hızlı ve iyi olsalar bile, hala ham terminal bant genişliğinizden bayt çalıyorlar. İmleci DEC VT uyumlu bir terminalde rastgele bir satıra taşımak için, gönderirsiniz ESC [ row ; col H. Bu 6-10 bayttır. Birden fazla terminal ile, işi ayırıyorsunuz, konumlandırma, optimizasyon, tamponlama ve diğer tüm işlemleri cursesyapma gereksinimini ortadan kaldırıyor ve birden fazla CPU çekirdeğini daha iyi kullanıyorsunuz.

5
+1, ancak tmux olayı sadece bazı ekstra kaçış kodlarının gönderilmesinden daha karmaşık. Terminallerin yarısını değil tüm pencereyi kaydırması amaçlanmıştır. Bu nedenle tmux sol bölmedeki tüm metni bir satır yukarı kaydırması gerektiğinde, sadece yeni bir satır oluşturamaz ve terminalin yukarı kaldırmasına izin vermez, tüm bölmeyi yeniden çizmek zorunda kalır.
Patrick

1
Oldukça doğru! Bunu unutmuştum. Orada rağmen olan ekran bölümünü kayabilir terminalleri edilmiş (IIRC denilen bu ekranın bir bölümünü 'koruma' - bu formlar, vb için kullanılmıştır), hiçbir zaman, özellikle esnek ve muhtemelen modern uç taklitleri tarafından desteklenmez. Bugün gerçekten uygulanmakta olan bazı tuhaf eski yönergeleri bulsanız bile.
Alexios

Bunu 3 yıl sonra cevaplamak, ancak birisinin bunu faydalı bulmasını umuyorum. Ben yaptığımda sadece lag fark dikey benim vim (evet, hatta NERDTree) bölünmüş fakat normal bölünmüş hiç kaydırma sırasında sorun görünmüyor.
shriek

17

Bu arada @Alexios tüm nedenleri oldukça iyi tarif etmiş, ağrıyı nispeten hafifleten birkaç şeyden bahsedebilirim:

  • bitmap fontlarını kullanın ( Terminal, Terminus- bu gerçekten harika bir tane),
  • kenar yumuşatma özelliğini kapatın veya en azından piksel altı görüntülemeyi kullanmamayı düşünün ,
  • KDE'nin terminalini kullan - konsole.

1
Ayrıca, ve bu acı verici olanı, terminalin boyutunu azaltır (OP 1920x1200 piksel bir pencere kullanıyor). Ben seviyorum büyük terminalleri ve maden ekranın neredeyse büyük dönene kadar büyürler, ancak terminali büyüdükçe terminali hızı düşer. Hatta konsole(bu lehime).
Alexios

3
konsoletembel ekran güncellemeleri yapar: hemen çıktı görüntülemek yerine, güncellemeleri "toplu" hale getirmek için daha fazla çıktı için biraz zaman bekler. Bu yüzden, OP'nin stres testine tamamen duyarlı olma noktasına gelince iyi performans gösteriyor.
ninjalj

2
Oldukça emin font oluşturma işlemi bir noktada önbelleğe alınır. F harfini temsil eden piksellerin, bir piksel haritasına her kopyalanışında vektör tanımından yeniden oluşturulduğunu sanmıyorum. (yeni bir boyutta veya yeni bir açıda işlenmesi gerekmedikçe). Gerçekten güzel bir bitmap yazı tipi olduğu gerçeğini tartışmayacağım, bu sadece istediğiniz görünüme sahiplerse, sadece görüntü için en iyi seçenek olabilir.
Peter Cordes
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.