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

59

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:

  1. Ouvrez une fenêtre tmux avec 2 panneaux
  2. 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
  3. 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.

utilisateur17537
la source
on dirait qu'il y a un gros tampon quelque part
Thorbjørn Ravn Andersen
2
Avis tty [1-6] ne sont pas toujours rapides au point de vue naturel. Sur l'une des machines que j'utilise, la console texte est très lente alors qu'un xterm fonctionne correctement.
Le

Réponses:

75

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:

  • Diminuer la taille du terminal. Mes propres terminaux ont tendance à grandir jusqu'à ce qu'ils remplissent les écrans, et ils deviennent lents à ce moment-là. Je suis exaspéré, agacé par les terminaux graphiques, puis je les redimensionne et tout va mieux. :)
  • (@poige) Utilisez un émulateur de terminal différent. Vous pouvez obtenir un gain de vitesse énorme au prix de certaines fonctionnalités modernes. xtermet rxvtfonctionne 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».
  • (@poige) N'utilisez pas de polices vectorielles. 1986 peut appeler et demander ses terminaux, mais vous ne pouvez pas nier qu'ils sont plus rapides. ;)
  • (@poige) Dust down le rasteriser de police en désactivant l'adressage anti-aliasing / sous-pixel et allusion. La plupart d'entre eux autorisent les remplacements dans les variables d'environnement, vous n'avez donc pas à le faire globalement. Remarque: inutile si vous choisissez une police bitmap.
  • Cela fera le plus mal: n'utilisez pas (plusieurs panneaux en même temps)tmux - exécutez deux terminaux distincts côte à côte. Lorsqu'il tmuxaffiche 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 envoyez ESC [ 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 reste curses, et optimisez l'utilisation de plusieurs cœurs de processeur.
Alexios
la source
5
+1, mais le problème tmux est encore plus compliqué que l'envoi de quelques codes d'échappement supplémentaires. Les terminaux sont conçus pour faire défiler la fenêtre entière, pas la moitié. Ainsi, lorsque tmux doit déplacer tout le texte dans le volet de gauche vers le haut d’une ligne, il ne peut pas simplement créer une nouvelle ligne et laisser le terminal la déplacer vers le haut, il doit redessiner l’ensemble du volet.
Patrick
1
Tout à fait raison! J'ai oublié cela. Bien que certains terminaux aient pu faire défiler une partie de l'écran (le IIRC s'appelait «protéger» une partie de l'écran - il était utilisé pour les formulaires, etc.), il n'a jamais été particulièrement flexible et n'est probablement pas pris en charge par les émulateurs de terminaux modernes. Même si vous trouvez des directives obsolètes vraiment bizarres encore mises en œuvre aujourd'hui.
Alexios
Répondre à cela après 3 ans, mais espérons que quelqu'un trouvera cela utile. Je remarque le décalage uniquement lorsque je réalise une division verticale dans mon vim (oui, même sous NERDTree), mais la division normale ne semble pas poser de problème lors du défilement.
Cri
17

Pendant ce temps @Alexios a très bien décrit toutes les raisons, je peux mentionner plusieurs choses qui soulagent relativement la douleur:

  • utiliser des polices bitmap ( Terminal, Terminus- c'est vraiment un super),
  • désactiver l'anti-aliasing ou au moins ne pas utiliser le rendu sous-pixel ,
  • utilisez le terminal de KDE - konsole.
poige
la source
1
En outre, et c’est le cas douloureux, diminuez la taille du terminal (le terminal opérateur utilise une fenêtre de 1920 x 1200 px). J'adore les grands terminaux, et le mien ont tendance à croître jusqu'à ce qu'ils obtiennent presque aussi grand que l'écran, mais la vitesse terminale diminue à mesure que le terminal se développe. Même konsole(ce que je préfère).
Alexios
3
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.
Ninjalj
2
Assez sûr que le rendu des polices est mis en cache à un moment donné. Je ne pense pas que les pixels représentant la lettre f soient restitués à partir de la définition du vecteur chaque fois qu'il est copié dans un pixmap. (sauf s'il doit être rendu dans une nouvelle taille ou un nouvel angle). Je ne contesterai pas le fait qu'il existe de très jolies polices bitmap, ce peut être la meilleure option, rien que pour l'apparence, si elles existent pour la taille souhaitée.
Peter Cordes