Czy emulator terminala może być tak szybki jak TTY 1-6?

59

Ostatnio próbowałem różnych emulatorów terminali, od wbudowanego terminalu gnome, aterm, xterm, wterm, aż do rxvt. Test, który przeprowadzam, jest w następującej kolejności:

  1. Otwórz okno tmux z 2 panelami
  2. Lewe okienko będzie zadaniem wymagającym intensywnego mówienia, na przykład grep a /et/c -rprostymtime seq -f 'blah blah %g' 100000
  3. Prawym okienkiem będzie okno vim z włączoną składnią, otwierające każdy plik zawierający więcej niż> 100 wierszy kodu.

Kiedy lewy panel drukuje dużo danych wyjściowych, prawy panel wydaje się być bardzo wolny i nie odpowiada, próbowałem przewijać w vimie, ale zmiana zajmuje 1-2 sekundy. Kiedy próbuję nacisnąć CtrlClewy panel, czeka ponad 10 sekund, zanim się zatrzyma

Kiedy robię to samo w TTY (naciśnięcie CTRL+ ALT+ ( F[1-6])), tak się nie dzieje i oba panele reagują bardzo szybko.

Odwróciłem niektóre konfiguracje, takie jak czcionki antyaliasowe, kolejność kolorowania, używam ustawień domyślnych i zmieniam na xmonad i openbox, ale to nic nie zmienia.

Rezultat time seq -f 'blah blah %g' 100000nie jest tak naprawdę różny wśród tych terminali, ale czas reakcji jest naprawdę inny, szczególnie gdy korzystam z tmux-a (lub innych multiplekserów). Do Twojej wiadomości, używam ich wszystkich w trybie zmaksymalizowanym.

Czytałem o terminalach buforowanych ramkami, ale nie jestem pewien, jak to działa i jak można go użyć do przyspieszenia emulatora terminala.

Moje pytanie brzmi: co sprawia, że ​​emulator terminala jest znacznie wolniejszy niż TTY? Czy jest jakaś możliwość, aby zrobić to tak szybko, jak TTY? Może przyspieszenie sprzętowe czy coś? Jedno wiem, że moja rozdzielczość na serwerze X podczas uruchamiania zmaksymalizowanego emulatora terminali to 1920x1080, a kiedy korzystam z TTY, jest mniej niż to, ale nie jestem pewien, jak to wpłynie na wydajność.

użytkownik17537
źródło
wygląda na to, że gdzieś jest duży bufor
Thorbjørn Ravn Andersen
2
Zauważ, że tty [1-6] nie zawsze są naturalnie szybkie. Na jednej z używanych przeze mnie maszyn konsola tekstowa działa bardzo wolno, a xterm działa przyzwoicie.
把 友情 留 在 无 盐

Odpowiedzi:

75

Gdy emulator terminala GUI drukuje ciąg, musi przekonwertować ciąg na punkty kodowe czcionki, wysłać punkty kodowe do mechanizmu renderowania czcionek, odzyskać mapę bitową i przesłać tę mapę bitową do wyświetlacza za pośrednictwem serwera X.

Moduł renderujący czcionki musi pobrać glify i uruchomić je (czy wiesz, że czcionki Truetype / Opentype to programy działające na maszynie wirtualnej w module renderującym czcionki?). Podczas uruchamiania każdego glifu podejmowana jest szalona liczba decyzji dotyczących metryk czcionek, kerningu (chociaż czcionki monospace i kerning nie mieszają się dobrze), zgodności z Unicode, i to jeszcze zanim dotrzemy do rasterizera, który prawdopodobnie używa sub Adresowanie pikseli. Terminal musi następnie zabrać bufor utworzony przez rasteriser czcionek i umieścić go we właściwym miejscu, dbając o konwersję formatu pikseli, kanały alfa (dla adresowania subpikseli), przewijanie (co wymaga więcej blittingu) i tak dalej.

Dla porównania, napisanie ciągu do wirtualnego terminala działającego w trybie tekstowym (uwaga: nie konsola graficzna) obejmuje zapisanie tego ciągu do pamięci wideo. 'Witaj świecie!' wymaga zapisania 13 bajtów (13 16-bitowych słów, jeśli chcesz też kolorów). Rasterizer czcionek X jeszcze nie rozpoczął ćwiczeń rozciągających i łamania kostek, i gotowe. Właśnie dlatego tryb tekstowy był tak niezwykle ważny w minionych dziesięcioleciach. Jest bardzo szybki do wdrożenia. Nawet przewijanie jest łatwiejsze niż myślisz: nawet w czcigodnym MDA i CGA opartym na Motoroli 6845, możesz przewijać ekran w pionie, zapisując pojedynczą 8-bitową wartość do rejestru (może być 16 ... to było za długo). Odświeżania ekranu obwodyzrobił resztę. Zasadniczo zmieniałeś adres początkowy bufora ramki.

Nic nie możesz zrobić, aby terminal graficzny był tak szybki jak terminal tekstowy na tym samym komputerze. Ale nie przejmuj się: były komputery z wolniejszymi trybami tekstowymi niż najwolniejszy graficzny terminal, jaki kiedykolwiek można zobaczyć na nowoczesnym komputerze. Oryginalny komputer IBM był dość zły (DOS przewijał oprogramowanie, wzdychał). Kiedy zobaczyłem moją pierwszą konsolę Minix na 80286, byłem zdumiony szybkością przewijania (skoku). Postęp jest dobry.

Aktualizacja: jak przyspieszyć terminal

@ poige wspomniał już o trzech w swojej odpowiedzi , ale oto moje własne zdanie na ich temat:

  • Zmniejsz rozmiar terminala. Moje własne terminale mają tendencję do wzrostu, dopóki nie wypełnią ekranów, i stają się powolne. Denerwuje mnie, denerwuję graficznymi terminalami, potem zmieniam ich rozmiar i wszystko jest lepsze. :)
  • (@poige) Użyj innego emulatora terminala. Możesz uzyskać ogromny wzrost prędkości kosztem niektórych nowoczesnych funkcji. xtermi rxvtdziała naprawdę dobrze, ma fantastyczny emulator terminala. Podejrzewam, że twoje testy mogły wykazać, że działają lepiej niż te „nowoczesne”.
  • (@poige) Nie używaj skalowalnych czcionek. 1986 może zadzwonić i poprosić o zwrot terminali, ale nie można zaprzeczyć, że są szybsze. ;)
  • (@poige) Ogłusz rasterizer czcionek , wyłączając antyaliasing / adresowanie subpikseli i podpowiedzi. Większość z nich pozwala na przesłonięcie zmiennych środowiskowych, więc nie musisz tego robić globalnie. Uwaga: bezcelowe, jeśli wybierzesz czcionkę bitmapową.
  • To najbardziej zaszkodzi: nie używaj (wiele paneli)tmux - uruchom dwa osobne terminale obok siebie. Kiedy tmuxwyświetla dwa panele, musi używać dyrektyw terminalu, aby często przesuwać kursor. Chociaż współczesne biblioteki terminali są bardzo szybkie i dobrze optymalizują, wciąż kradną bajty z przepustowości surowego terminala. Aby przenieść kursor do dowolnego wiersza na terminalu zgodnym z DEC VT, wysyłasz ESC [ row ; col H. To 6–10 bajtów. Dzięki wielu terminalom segregujesz pracę, eliminując potrzebę pozycjonowania, optymalizacji, buforowania i wszystkich innych czynności cursesoraz lepiej wykorzystując wiele rdzeni procesora.
Alexios
źródło
5
+1, ale funkcja tmux jest jeszcze bardziej skomplikowana niż wysyłanie dodatkowych kodów ucieczki. Terminale służą do przewijania całego okna, a nie jego połowy. Więc kiedy tmux musi przesunąć cały tekst w lewym panelu w górę linii, nie może po prostu utworzyć nowej linii i pozwolić terminalowi przesunąć ją w górę, musi przerysować cały panel.
Patrick
1
Całkiem dobrze! Zapomniałem o tym. Chociaż nie mają już terminale, które mogą przewinąć część ekranu (IIRC to było nazywane „ochrony” część ekranu - to użyto formy etc), to nigdy nie było szczególnie elastyczne i prawdopodobnie nie jest obsługiwana przez nowoczesne emulatory terminali. Mimo, że nadal istnieją niektóre naprawdę dziwne przestarzałe dyrektywy.
Alexios
Odpowiadając na to po 3 latach, ale mam nadzieję, że ktoś uzna to za przydatne. Widzę opóźnienie tylko wtedy, gdy wykonuję pionowy podział w moim vimie (tak, nawet NERDTree), ale normalny podział nie wydaje się być problemem podczas przewijania.
wrzask
17

Tymczasem @Alexios dość dobrze opisał wszystkie powody, mogę wymienić kilka rzeczy, które stosunkowo łagodzą ból:

  • używaj czcionek bitmapowych ( Terminal, Terminus- to naprawdę świetna),
  • wyłącz wygładzanie lub przynajmniej nie używaj renderowania subpikseli ,
  • użyj terminalu KDE - konsole.
poige
źródło
1
Również i to jest bolesne, zmniejsz rozmiar terminala (OP używa okna 1920x1200px). Ja uwielbiam duże terminale i kopalni rosną aż oni dostać prawie tak duży jak na ekranie, ale prędkość spada terminala jako terminal rośnie. Nawet konsole(co mi się podoba).
Alexios
3
konsolerobi leniwe aktualizacje ekranu: zamiast od razu wyświetlać dane wyjściowe, czeka trochę czasu na więcej danych wyjściowych, aby wykonać aktualizacje „wsadowe”. Dlatego działa tak dobrze, że całkowicie reaguje w teście warunków skrajnych PO.
ninjalj
2
W pewnym momencie buforowanie renderowania czcionek jest buforowane. Nie sądzę, aby piksele reprezentujące literę f były renderowane ponownie z definicji wektora za każdym razem, gdy jest kopiowana do mapy pikseli. (chyba że musi być renderowany w nowym rozmiarze lub pod innym kątem). Nie będę kwestionować faktu, że istnieją naprawdę ładne czcionki bitmapowe, które mogą być najlepszą opcją dla samego wyglądu, jeśli zdarzają się one dla pożądanego rozmiaru.
Peter Cordes,