Un emulatore di terminale può essere veloce come TTY 1-6?

Ultimamente ho provato vari emulatori di terminali, da gnome-terminal integrato, aterm, xterm, wterm, a rxvt. Il test che ho fatto è in questo ordine:

1. Apri una finestra di tmux con 2 riquadri
2. Il riquadro sinistro sarà un'attività ad alta intensità come grep a /et/c -ro semplicetime seq -f 'blah blah %g' 100000
3. Il riquadro destro sarà una finestra vim con sintassi attiva, che apre qualsiasi file con più di> 100 righe di codice.

Quando il riquadro di sinistra stampa molto output, il riquadro di destra sembra essere molto lento e non risponde, ho provato a scorrere in VIM ma ci vogliono 1-2 secondi per cambiare. Quando provo a premere CtrlCsul riquadro sinistro, attende per più di 10 secondi prima di arrestarsi

Quando faccio la stessa cosa in TTY (premendo CTRL+ ALT+ ( F[1-6])), non succede ed entrambi i riquadri sono molto reattivi.

Ho disattivato alcune configurazioni come i caratteri antialias, il turno di colorazione, l'uso delle impostazioni predefinite e il passaggio a xmonad e openbox, ma non cambia nulla.

Il risultato time seq -f 'blah blah %g' 100000non è molto diverso tra questi terminali, ma la reattività è davvero diversa, specialmente quando sto eseguendo il riquadro spm tmux (o altri multiplexer). Cordiali saluti, li sto eseguendo tutti in una modalità massimizzata.

Ho letto dei terminali con frame buffer ma non sono sicuro di come funzioni e come possa essere usato per velocizzare il mio emulatore di terminale.

Quindi la mia domanda è: cosa rende l'emulatore di terminale molto più lento di TTY? C'è qualche possibilità di farlo velocemente come TTY? Forse accelerazione hardware o qualcosa del genere ?. Una cosa che so, la mia risoluzione nel server X quando eseguo un emulatore di terminale ingrandito è 1920x1080, e quando eseguo TTY è inferiore a quello, ma non sono sicuro di come ciò influirebbe sulle prestazioni.

Quando un emulatore di terminale GUI stampa una stringa, deve convertire la stringa in punti di codice carattere, inviare i punti di codice a un renderer di caratteri, recuperare una bitmap e trasferirla sul display tramite il server X.

Il renderer dei font deve recuperare i glifi ed eseguirli (lo sapevate che i font TrueType / Opentype sono programmi in esecuzione all'interno di una macchina virtuale nel renderer dei font?). Durante il processo di esecuzione di ogni glifo, viene preso un numero folle di decisioni in merito a metriche dei caratteri, crenatura (sebbene i caratteri monospaziali e crenatura non si mescolino bene), conformità Unicode, e questo è ancora prima di raggiungere il rasterizzatore che probabilmente usa sub -pixel di indirizzamento. Il terminale deve quindi prendere il buffer prodotto dal font rasteriser e trasferirlo nel posto giusto, occupandosi delle conversioni del formato dei pixel, dei canali alfa (per l'indirizzamento dei sub-pixel), dello scorrimento (che comporta più blitting), eccetera.

In confronto, scrivere una stringa su un Terminale virtuale in esecuzione in modalità testo (nota: non una console grafica) implica scrivere quella stringa nella memoria video. 'Ciao mondo!' comporta la scrittura di 13 byte (13 parole a 16 bit se si vogliono anche i colori). Il rasterizzatore di font X non ha ancora iniziato i suoi esercizi di stretching e il cracking delle nocche, e abbiamo finito. Questo è il motivo per cui la modalità testo era così incredibilmente importante nei decenni passati. È molto veloce da implementare. Anche lo scorrimento è più facile di quanto pensi: anche sul venerabile Motorola MDA e CGA basato su Motorola 6845, potresti scorrere lo schermo verticalmente scrivendo un singolo valore di 8 bit in un registro (potrebbe essere 16 ... è stato troppo lungo). Il circuito di aggiornamento dello schermoha fatto il resto. Stavi essenzialmente cambiando l'indirizzo iniziale del frame buffer.

Non c'è niente che puoi fare per creare un terminale grafico veloce come un terminale in modalità testo sullo stesso computer. Ma prendi il cuore: ci sono stati computer con modalità di testo più lente rispetto al terminale grafico più lento che tu abbia mai visto su un computer moderno. Il PC IBM originale era piuttosto male (DOS eseguiva lo scorrimento del software, sospiro). Quando ho visto la mia prima console Minix su un 80286, sono rimasto sorpreso dalla velocità dello scorrimento (salto). I progressi sono buoni.

Aggiornamento: come accelerare il terminale

@ poige ne ha già menzionato tre nella sua risposta , ma ecco la mia opinione su di loro:

• Ridurre le dimensioni del terminale. I miei terminali tendono a crescere fino a quando non riempiono gli schermi e diventano lenti mentre lo fanno. Sono esasperato, infastidito dai terminali grafici, quindi li ridimensiono e tutto va meglio. :)
• (@poige) Utilizzare un emulatore di terminale diverso. È possibile ottenere un enorme aumento di velocità al costo di alcune funzionalità moderne. xterme rxvtfunziona davvero bene, ha un emulatore di terminale fantastico. Sospetto che i tuoi test possano aver dimostrato che funzionano meglio di quelli "moderni".
• (@poige) Non usare caratteri scalabili. Il 1986 potrebbe chiamare e chiedere indietro i suoi terminali, ma non si può negare che siano più veloci. ;)
• (@poige) Abbassa il rasterizzatore di caratteri disattivando l'indirizzamento e i suggerimenti di anti-alias / sub-pixel. La maggior parte di essi consente l'override delle variabili di ambiente, quindi non è necessario farlo a livello globale. Nota: inutile se si sceglie un carattere bitmap.
• Questo danneggerà di più: non usare (più riquadri in)tmux - esegui due terminali separati uno accanto all'altro. Quando tmuxvisualizza due riquadri, deve utilizzare le direttive del terminale per spostare il cursore molto. Anche se le moderne librerie di terminali sono molto veloci e sono in grado di ottimizzare, stanno ancora rubando byte dalla larghezza di banda del terminale non elaborata. Per spostare il cursore su una riga arbitraria su un terminale compatibile con DEC VT, si invia ESC [ row ; col H. Sono 6-10 byte. Con più terminali, stai separando il lavoro, eliminando la necessità di posizionamento, ottimizzazione, buffering e tutto il resto curses, e facendo un uso migliore di più core della CPU.

Nel frattempo @Alexios ha descritto abbastanza bene tutti i motivi, posso citare diverse cose, che alleviano relativamente il dolore:

• usa i caratteri bitmap ( Terminal, Terminus- è davvero fantastico),
• disattiva l'antialiasing o considera almeno di non utilizzare il rendering sub-pixel ,
• usa il terminale di KDE - konsole.