J'ai récemment essayé divers émulateurs de terminaux, du gnome-terminal intégré, aterm, xterm, wterm à rxvt. Le test que j'ai fait est dans cet ordre:
- Ouvrez une fenêtre tmux avec 2 panneaux
- Le volet de gauche sera une tâche à forte intensité verbeuse telle que
grep a /et/c -rou une simpletime seq -f 'blah blah %g' 100000 - Le volet de droite sera une fenêtre vim avec une syntaxe activée, ouvrant tout fichier contenant plus de 100 lignes de code.
Lorsque le volet de gauche imprime beaucoup de résultats, le volet de droite semble très lent et ne répond pas. J'ai essayé de faire défiler dans vim mais cela prend 1 à 2 secondes pour que cela change. Lorsque j'essaie d'appuyer CtrlCsur le volet de gauche, il attend plus de 10 secondes avant de s'arrêter
Lorsque je fais la même chose dans TTY (en appuyant sur CTRL+ ALT+ ( F[1-6])), cela ne se produit pas et les deux volets sont très réactifs.
J'ai modifié certaines configurations telles que les polices antialias, le changement de couleur, l'utilisation des paramètres par défaut et le changement en xmonad et openbox, mais cela ne change rien.
Le résultat de time seq -f 'blah blah %g' 100000n'est pas vraiment différent entre ces terminaux, mais la réactivité est vraiment différente, en particulier lorsque je suis en train de faire tourner spmed pane tmux (ou d'autres multiplexeurs). Pour votre information, je les utilise tous dans un mode maximisé.
J'ai lu des articles sur les terminaux à tampon de cadre, mais je ne sais pas comment cela fonctionne ni comment il peut être utilisé pour accélérer mon émulateur de terminal.
Ma question est donc la suivante: pourquoi l'émulateur de terminal est-il beaucoup plus lent que TTY? Y a-t-il une possibilité de le rendre aussi rapide qu'un ATS? Peut-être que l'accélération matérielle ou quelque chose? Une chose que je sais, ma résolution sur le serveur X lors de l’exécution d’un émulateur de terminal maximisé est de 1920x1080, et lorsque j’exécute TTY, elle est inférieure à cela, mais je ne suis pas sûr de l’impact que cela pourrait avoir sur les performances.
Réponses:
Lorsqu'un émulateur de terminal à interface graphique imprime une chaîne, il doit la convertir en points de code de police, envoyer les points de code à un rendu de police, récupérer une image bitmap et l' insérer dans l'affichage via le serveur X.
Le moteur de rendu de police doit extraire les glyphes et les exécuter (saviez-vous que les polices TrueType / Opentype sont des programmes exécutés dans une machine virtuelle dans le moteur de rendu de police?). Au cours du processus d’exécution de chaque glyphe, un nombre insensé de décisions sont prises concernant les métriques de police, le crénage (bien que les polices monospaces et le crénage ne se mélangent pas bien), la conformité Unicode, et ce, avant même d’atteindre le rasteriser qui utilise -adressage en pixels. Le terminal doit ensuite prendre la mémoire tampon produite par le rasteriser et la placer au bon endroit, en prenant en charge les conversions au format pixel, les canaux alpha (pour l’adressage sous-pixel), le défilement (ce qui implique davantage de réduction), etc.
En comparaison, écrire une chaîne sur un terminal virtuel fonctionnant en mode texte (remarque: ce n'est pas une console graphique) implique l'écriture de cette chaîne dans la mémoire vidéo. 'Bonjour le monde!' implique l’écriture de 13 octets (13 mots de 16 bits si vous voulez aussi des couleurs). Le rasteriser de police X n'a même pas encore commencé ses exercices d'étirement et de craquage des doigts, et nous avons terminé. C'est pourquoi le mode texte était si important au cours des dernières décennies. C'est très rapide à mettre en œuvre. Même le défilement est plus facile que vous ne le pensez: même sur les vénérables MDA et CGA de Motorola 6845, vous pouvez faire défiler l'écran verticalement en écrivant une seule valeur de 8 bits dans un registre (il pourrait être de 16 ... c'est trop long). Le circuit de rafraîchissement de l'écranfait le reste. Vous changiez essentiellement l'adresse de début du tampon de trame.
Vous ne pouvez rien faire pour créer un terminal graphique aussi rapidement qu'un terminal en mode texte sur le même ordinateur. Mais ne vous inquiétez pas: certains ordinateurs ont des modes de texte plus lents que le terminal graphique le plus lent que vous puissiez voir sur un ordinateur moderne. Le PC IBM original était plutôt mauvais (DOS faisait défiler le logiciel, soupir). Quand j'ai vu ma première console Minix sur un 80286, j'ai été étonné par la vitesse de défilement. Les progrès sont bons.
Mise à jour: comment accélérer le terminal
@ poige en a déjà mentionné trois dans sa réponse , mais voici ce que je pense d' eux:
xtermetrxvtfonctionne vraiment bien, il a un émulateur de terminal fantastique. Je soupçonne que vos tests ont pu montrer qu'ils fonctionnent mieux que les tests «modernes».tmux- exécutez deux terminaux distincts côte à côte. Lorsqu'iltmuxaffiche deux volets, il doit utiliser les directives de terminal pour déplacer le curseur beaucoup. Même si les bibliothèques de terminaux modernes sont très rapides et optimales, elles volent toujours des octets dans la bande passante brute de votre terminal. Pour envoyer le curseur sur une ligne quelconque d'un terminal compatible avec DEC VT, vous envoyezESC [ row ; col H. C'est 6-10 octets. Avec plusieurs terminaux, vous séparez le travail, supprimez le besoin de positionnement, d'optimisation, de mise en mémoire tampon et de tout le restecurses, et optimisez l'utilisation de plusieurs cœurs de processeur.la source
Pendant ce temps @Alexios a très bien décrit toutes les raisons, je peux mentionner plusieurs choses qui soulagent relativement la douleur:
Terminal,Terminus- c'est vraiment un super),konsole.la source
konsole(ce que je préfère).konsoleeffectue des mises à jour d'écran paresseux: au lieu d'afficher immédiatement la sortie, il attend un peu de temps pour obtenir plus de sortie, de manière à "mettre à jour" les mises à jour. C'est pourquoi il fonctionne si bien, au point d'être totalement réactif au test de résistance du PO.