Un émulateur de terminal peut-il être aussi rapide que TTY 1-6?

J'ai essayé dernièrement divers émulateurs de terminal, du terminal gnome embedded, aterm, xterm, wterm, à rxvt. Le test que j'ai fait est dans cet ordre:

  1. Ouvrez une window tmux avec 2 panneaux
  2. Le volet gauche sera une tâche grep a /et/c -r comme grep a /et/c -r ou un simple time seq -f 'blah blah %g' 100000
  3. Le volet de droite sera une window vim avec la syntaxe, ouvrant tout file ayant plus de 100 lignes de code.

Quand le panneau de gauche imprime beaucoup de sortie, le panneau de droite semble être très lent et ne répond pas, j'ai essayé de faire défiler dans vim mais cela prend 1-2 secondes pour qu'il change. Lorsque j'essaie d'appuyer sur Ctrl C dans le volet de gauche, il attend plus de 10 secondes avant de l'arrêter

Quand je fais la même chose dans TTY (en appuyant sur CTRL + ALT + ( F [1-6] )), cela n'arrive pas et les deux volets sont très réactifs.

J'ai tourné de certaines config comme les fonts antialias, le changement de couleur, j'utilise les parameters par défaut et je passe à xmonad et openbox, mais ça ne change rien.

Le résultat du time seq -f 'blah blah %g' 100000 n'est pas vraiment différent entre ces terminaux, mais la réactivité est vraiment différente, surtout quand je suis en train de faire tourner un volet tmux (ou d'autres multiplexeurs). Pour votre information, je les cours tous dans un mode agrandi.

J'ai lu sur les terminaux à tampon d'image, mais je ne sais pas comment cela fonctionne et comment peut-il être utilisé pour accélérer mon émulateur de terminal.

Ma question est donc: qu'est-ce qui rend l'émulateur de terminal beaucoup plus lent que TTY? Y a-t-il une possibilité de le faire aussi vite que TTY? Peut-être une accélération matérielle ou quelque chose ?. Une chose que je sais, ma résolution dans le server X lors de l'exécution d'un émulateur de terminal maximisé est 1920×1080, et quand je lance TTY c'est less que cela, mais je ne sais pas comment cela affecterait les performances.

Lorsqu'un émulateur de terminal graphique imprime une string, il doit convertir la string en points de code de police, envoyer les codes à un moteur de rendu de police, récupérer un bitmap et envoyer ce bitmap à l'affichage via le server X.

Le rendu de police doit récupérer les glyphes et les exécuter (saviez-vous que les fonts Truetype / Opentype sont des programmes exécutés à l'intérieur d'une machine virtuelle dans le rendu de police?). Au cours du process d'exécution de chaque glyphe, un nombre déraisonnable de décisions sont sockets en ce qui concerne les mésortingques de police, le crénage (quoique les fonts monospace et le crénage ne se mélangent pas bien), la conformité Unicode et c'est avant même le rastériser qui utilise probablement sub -pixel adressage. Le terminal doit alors prendre le tampon produit par le trameur de fonts et le placer au bon endroit, en prenant soin des conversions au format pixel, des canaux alpha (pour l'adressage sous-pixel), du défilement (qui implique plus de bling), et cetera.

En comparaison, l'écriture d'une string dans un Terminal Virtuel s'exécutant en mode text (note: pas une console graphique) implique l'écriture de cette string dans la memory video. 'Bonjour le monde!' implique l'écriture de 13 octets (13 mots de 16 bits si vous voulez des colors aussi). Le rasteriseur des fonts X n'a ​​même pas encore commencé ses exercices d'étirement et ses articulations se fissurent encore, et nous avons terminé. C'est pourquoi le mode text était si important dans les décennies passées. 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 Motorola 6845, vous pouvez faire défiler l'écran verticalement en écrivant une seule valeur de 8 bits dans un registre (il pourrait être 16 … trop long). Le circuit de rafraîchissement de l'écran a fait le rest. Vous changiez essentiellement l'adresse de début du tampon d'image.

Vous ne pouvez rien faire pour créer un terminal graphique aussi rapidement qu'un terminal en mode text sur le même ordinateur. Mais prenez courage: il y a eu des ordinateurs avec des modes de text plus lents que le terminal graphique le plus lent que vous puissiez voir sur un ordinateur moderne. Le PC IBM d'origine était assez mauvais (DOS faisait défiler le logiciel, soupir). Quand j'ai vu ma première console Minix sur un 80286, j'ai été étonné de la vitesse du défilement (saut). Le progrès est bon.

Mise à jour: comment accélérer le terminal

@ poige a déjà mentionné trois dans sa réponse , mais voici ma propre prise sur eux:

  • Diminuez la taille du terminal. Mes propres terminaux ont tendance à grandir jusqu'à ce qu'ils remplissent les écrans, et ils deviennent lents comme ils le font. Je suis exaspéré, agacé par les terminaux charts, puis je les redimensionne et tout va mieux. 🙂
  • (@poige) Utilisez un émulateur de terminal différent. Vous pouvez get une augmentation de vitesse énorme au prix de certaines fonctionnalités modernes. xterm et rxvt fonctionnent vraiment bien, il a un émulateur de terminal fantastique. Je soupçonne que vos tests ont montré qu'ils sont plus performants que les tests «modernes».
  • (@poige) N'utilisez pas de fonts évolutives. 1986 peut appeler et requestr à ses terminaux de return, mais vous ne pouvez pas nier qu'ils sont plus rapides. 😉
  • (@poige) Arrêtez le tramage des fonts en désactivant l'adressage anti-aliasing / sous-pixel et les suggestions. La plupart d'entre eux autorisent les surcharges dans les variables d'environnement, donc vous n'avez pas à le faire globalement. Note: inutile si vous choisissez une police bitmap.
  • Cela nuira le plus: n'utilisez pas (plusieurs volets) tmux – exécutez deux terminaux séparés côte à côte. Lorsque tmux affiche deux volets, il doit utiliser les directives du terminal pour déplacer le slider. Même si les bibliothèques de terminaux modernes sont très rapides et efficaces, elles volent encore des octets à partir de votre bande passante brute. Pour déplacer le slider sur une ligne arbitraire sur un terminal compatible DEC VT, vous envoyez ESC [ row ; col H ESC [ row ; col H C'est 6-10 octets. Avec plusieurs terminaux, vous séparez le travail, en supprimant le besoin de positionnement, d'optimization, de mise en memory tampon et de tous les autres trucs, et en utilisant au mieux plusieurs cœurs de processeur.

Pendant ce time @Alexios ont assez bien décrit toutes les raisons, je peux mentionner plusieurs choses, qui soulagent relativement la douleur:

  • utiliser des fonts bitmap ( Terminal , Terminus – c'est vraiment génial),
  • désactiver l'anti-aliasing, ou envisager au less de ne pas utiliser le rendu sous-pixel ,
  • utilisez le terminal de KDE – konsole .