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

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ść.

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.

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.