Terminal: Taper à l'intérieur du terminal WSL par défaut est incroyable, pourquoi est-il meilleur que toutes les autres applications?

Créé le 14 déc. 2018  ·  8Commentaires  ·  Source: microsoft/terminal

Désolé, ce n'est pas un problème, mais plutôt une suggestion / demande de ne pas casser ce que vous avez fait avec le terminal WSL par défaut (Ubuntu en particulier) étant si réactif lorsqu'il s'agit de rendre les caractères à l'écran après avoir appuyé sur un clé.

Taper dans le terminal WSL par défaut donne l'impression de taper à l'antenne. Il y a une douceur qui n'est présente dans aucune autre application Windows, pas même notepad.exe . Si vous avez l'impression d'avoir 10 ms de décalage d'entrée au lieu de 75 ms + pour tous les autres Windows (et 200-250 ms + pour la plupart des applications basées sur Electron).

Qu'est-ce qui fait que le terminal WSL se sent mieux que notepad.exe et cette amélioration de l'interface utilisateur fera-t-elle son chemin vers toutes les applications Windows à l'avenir?

N'hésitez pas à le fermer si vous ne souhaitez pas en discuter. Je l'ai principalement ouvert pour faire prendre conscience à quel point il est bon, espérons-le, d'éviter qu'un certain type de régression ne se produise à l'avenir.

Issue-Question Product-Conhost

Commentaire le plus utile

Cela ne me dérange vraiment pas que quelqu'un passe et décide de nous dire que nous faisons du bon travail à quelque chose. Nous entendons tellement de plaintes chaque jour qu'un article comme celui-ci est une bouffée d'air frais. Merci pour vos remerciements!

De plus, je suis heureux d'en discuter avec vous jusqu'à ce que vous en ayez marre de le lire. Veuillez demander les suites que vous souhaitez. Je m'épanouis en bavardant sur mon travail. : P

Si je devais faire une supposition éclairée sur ce qui nous rend plus rapides que n'importe quelle autre application sous Windows pour mettre votre texte à l'écran ... je dirais que c'est parce que c'est littéralement notre seul travail! Aussi probablement parce que nous utilisons darn près des API les plus anciennes et les plus basses dont Windows dispose pour accomplir ce travail.

Presque tout ce que vous avez énuméré a une sorte de couche ou de cadre impliqué, ou de très nombreuses couches et cadres, lorsque vous commencez à parler d'Electron et de Javascript. Nous ne le faisons pas.

Nous avons une fenêtre nue et super non spéciale sans contrôle supplémentaire. Nous recevons nos clés à peine au-dessus du noyau étant donné que nous les traitons à partir de messages de fenêtre et non à partir d'une sorte de cadre d'événement commun à à peu près tout autre cadre d'interface utilisateur plus compliqué que le nôtre (WPF, WinForms, UWP, Électron). Et nous vidons notre texte directement sur la surface de la fenêtre en utilisant PolyTextOut de GDI sans fioritures.

Même notepad.exe a au moins plusieurs contrôles sur sa fenêtre et utilise probablement (je n'ai pas regardé) une sorte de cadre de bibliothèque dans le contrôle d'édition pour comprendre sa disposition de texte (qui utilise probablement une autre bibliothèque cadre de soutien à l'internationalisation ...)

Bien sûr, cela signifie également que nous avons des compromis. Nous ne prenons pas en charge le texte entièrement international comme presque toutes les autres applications. RTL? Aucune zone de go pour le moment. Paires de substitution et emoji? Nous y arrivons mais pas encore. Des scripts indiques? Nan.

Pourquoi sommes-nous comme ça? D'une part, conhost.exe est vieux comme de la saleté. Il doit utiliser la couche inférieure en métal nu de tout, car il a été créé avant la création de la plupart de ces autres cadres. Et aussi il maintient le niveau aussi bas / bas que possible car c'est à peu près la première chose à soulever lors de la mise en place d'une nouvelle édition de système d'exploitation ou d'un nouveau périphérique avant d'avoir toutes les bonnes choses comme les frameworks ou ce que ces frameworks nécessitent pour fonctionner. De plus, il est écrit en C / C ++, ce qui est à peu près aussi bas et nu que possible.

Cette amélioration de l'interface utilisateur sera-t-elle disponible pour d'autres applications sur Windows? Presque certainement pas. Ils ont trop de choses à faire, ce qui est à la fois une bonne et une mauvaise chose. Je suis jaloux de leur capacité à appeler simplement une méthode et un texte de mise en page d'une manière simple dans n'importe quelle langue sans calculer manuellement les pixels ou se soucier des styles qui s'appliquent à leur police. Mais mes calculs manuels de pixels, mes calculs de région sales, ma folie de région de défilement, etc. Je suis également jaloux que lorsque quelqu'un dit "hé, pouvez-vous ajouter une barre d'état au bas de votre fenêtre" qu'il puisse à peu près cliquer et faire glisser cela en place avec son cadre d'interface utilisateur et cela fonctionnera là où, pour nous, c'est été un élément de l'arriéré pour toujours et me donne des brûlures d'estomac à penser à la mise en œuvre.

Essayons-nous de l'empêcher de régresser? Oui! À l'heure actuelle, c'est une sorte de processus manuel. Nous identifions que quelque chose devient lent, puis nous sortons WPR et commençons à prendre des traces. Nous regardons les chemins chauds et essayons de raisonner ce qui se passe, puis de les améliorer. Par exemple, au cours du ou des deux derniers cycles, nous nous sommes concentrés sur les allocations de tas en tant que domaine majeur dans lequel nous pourrions améliorer nos performances de bout en bout, en modifiant une tonne de notre code pour utiliser des façades de type itérateur construites en pile sur la demande sous-jacente. tampon au lieu de le traduire et de l'allouer dans un nouvel espace de tas pour chaque niveau de traitement.

En passant ,

S'il y a autre chose que vous aimeriez savoir, faites-le moi savoir. Je pourrais continuer toute la journée. J'ai supprimé comme 15 tangentes de cette réponse avant de la publier ....

Tous les 8 commentaires

Cela ne me dérange vraiment pas que quelqu'un passe et décide de nous dire que nous faisons du bon travail à quelque chose. Nous entendons tellement de plaintes chaque jour qu'un article comme celui-ci est une bouffée d'air frais. Merci pour vos remerciements!

De plus, je suis heureux d'en discuter avec vous jusqu'à ce que vous en ayez marre de le lire. Veuillez demander les suites que vous souhaitez. Je m'épanouis en bavardant sur mon travail. : P

Si je devais faire une supposition éclairée sur ce qui nous rend plus rapides que n'importe quelle autre application sous Windows pour mettre votre texte à l'écran ... je dirais que c'est parce que c'est littéralement notre seul travail! Aussi probablement parce que nous utilisons darn près des API les plus anciennes et les plus basses dont Windows dispose pour accomplir ce travail.

Presque tout ce que vous avez énuméré a une sorte de couche ou de cadre impliqué, ou de très nombreuses couches et cadres, lorsque vous commencez à parler d'Electron et de Javascript. Nous ne le faisons pas.

Nous avons une fenêtre nue et super non spéciale sans contrôle supplémentaire. Nous recevons nos clés à peine au-dessus du noyau étant donné que nous les traitons à partir de messages de fenêtre et non à partir d'une sorte de cadre d'événement commun à à peu près tout autre cadre d'interface utilisateur plus compliqué que le nôtre (WPF, WinForms, UWP, Électron). Et nous vidons notre texte directement sur la surface de la fenêtre en utilisant PolyTextOut de GDI sans fioritures.

Même notepad.exe a au moins plusieurs contrôles sur sa fenêtre et utilise probablement (je n'ai pas regardé) une sorte de cadre de bibliothèque dans le contrôle d'édition pour comprendre sa disposition de texte (qui utilise probablement une autre bibliothèque cadre de soutien à l'internationalisation ...)

Bien sûr, cela signifie également que nous avons des compromis. Nous ne prenons pas en charge le texte entièrement international comme presque toutes les autres applications. RTL? Aucune zone de go pour le moment. Paires de substitution et emoji? Nous y arrivons mais pas encore. Des scripts indiques? Nan.

Pourquoi sommes-nous comme ça? D'une part, conhost.exe est vieux comme de la saleté. Il doit utiliser la couche inférieure en métal nu de tout, car il a été créé avant la création de la plupart de ces autres cadres. Et aussi il maintient le niveau aussi bas / bas que possible car c'est à peu près la première chose à soulever lors de la mise en place d'une nouvelle édition de système d'exploitation ou d'un nouveau périphérique avant d'avoir toutes les bonnes choses comme les frameworks ou ce que ces frameworks nécessitent pour fonctionner. De plus, il est écrit en C / C ++, ce qui est à peu près aussi bas et nu que possible.

Cette amélioration de l'interface utilisateur sera-t-elle disponible pour d'autres applications sur Windows? Presque certainement pas. Ils ont trop de choses à faire, ce qui est à la fois une bonne et une mauvaise chose. Je suis jaloux de leur capacité à appeler simplement une méthode et un texte de mise en page d'une manière simple dans n'importe quelle langue sans calculer manuellement les pixels ou se soucier des styles qui s'appliquent à leur police. Mais mes calculs manuels de pixels, mes calculs de région sales, ma folie de région de défilement, etc. Je suis également jaloux que lorsque quelqu'un dit "hé, pouvez-vous ajouter une barre d'état au bas de votre fenêtre" qu'il puisse à peu près cliquer et faire glisser cela en place avec son cadre d'interface utilisateur et cela fonctionnera là où, pour nous, c'est été un élément de l'arriéré pour toujours et me donne des brûlures d'estomac à penser à la mise en œuvre.

Essayons-nous de l'empêcher de régresser? Oui! À l'heure actuelle, c'est une sorte de processus manuel. Nous identifions que quelque chose devient lent, puis nous sortons WPR et commençons à prendre des traces. Nous regardons les chemins chauds et essayons de raisonner ce qui se passe, puis de les améliorer. Par exemple, au cours du ou des deux derniers cycles, nous nous sommes concentrés sur les allocations de tas en tant que domaine majeur dans lequel nous pourrions améliorer nos performances de bout en bout, en modifiant une tonne de notre code pour utiliser des façades de type itérateur construites en pile sur la demande sous-jacente. tampon au lieu de le traduire et de l'allouer dans un nouvel espace de tas pour chaque niveau de traitement.

En passant ,

S'il y a autre chose que vous aimeriez savoir, faites-le moi savoir. Je pourrais continuer toute la journée. J'ai supprimé comme 15 tangentes de cette réponse avant de la publier ....

En parlant d'API Windows de bas niveau, j'ai trouvé que tous les composants du mode utilisateur de la console (conhost.exe, cmd.exe ...) et de WSL (wsl.exe, LxssManager.dll ...) utilisent énormément C ++ _STL_. Par exemple, dans la manipulation de chaînes, l'allocation de mémoire, les tables virtuelles, etc. Y aura-t-il une amélioration des performances si seul C est utilisé?

Je ne les considérerais pas comme utilisant "énormément" C ++ STL. Ils utilisent certainement certaines des collections et peut-être un peu de manipulation de chaînes et un algorithme ici ou là. J'ai l'impression qu'il y a beaucoup plus à STL que ces quelques bits.

Mais de toute façon ... la plupart des choses que vous décrivez ont été écrites directement en C il y a quelque temps. Nous avons utilisé de manière sélective C ++ et STL dans de plus en plus d'entre eux comme un compromis conscient. Tant que nous sommes bien conscients de ce que font les modèles sous le capot et que nous utilisons soigneusement les bons, nous n'échangeons généralement qu'une très petite quantité de performances tout en gagnant une sécurité et une facilité de programmation importantes.

La sécurité est en fait la principale raison pour laquelle nous utilisons des modèles STL plutôt que d'essayer de créer nos propres structures chaque fois que possible. L'utilisation des modèles STL pour les collections et les chaînes nous accorde généralement une vérification des limites qui, autrement, devrait être effectuée manuellement de manière sujette aux erreurs (ou pas du tout!)

De plus, je ne suis pas absolument sûr qu'avoir 17 implémentations différentes de files d'attente et de listes liées dans le code de la console quand il était simple C était globalement meilleur pour les performances que d'utiliser std :: queue et std :: list aujourd'hui. Il a probablement consommé plus d'espace sur le disque pour chaque implémentation individuelle, ce qui représente un type de problème de performances différent (stockage et E / S de chargement de page).

Merci beaucoup d'avoir pris le temps d'écrire cette réponse, et pas de problème d'éloges.

Au cours des deux derniers mois, je cherchais une bonne configuration de terminal, et je pense que ubuntu.exe avec tmux est aussi proche de la perfection que vous pouvez obtenir avec les outils que nous avons aujourd'hui. Le terminal ubuntu.exe lui-même est extrêmement rapide et tmux vous offre tous les avantages de la vie (onglets, volets séparés, recherche de tampon, etc.).

J'attends vraiment avec impatience les futures versions qui rendent les thèmes de couleur plus compatibles et les améliorations liées aux propriétés telles que les raccourcis clavier pour zoomer +/- sur la taille de la police.

@miniksa : Merci pour un message très intéressant!

nous utilisons darn près des API les plus anciennes et les plus basses dont Windows dispose pour accomplir ce travail.

J'étais curieux à ce sujet depuis un moment. Vous semblez faire référence aux différentes API Win32 (USER32 / GDI32). Récemment, je ne suis plus sûr de savoir s'ils sont toujours aussi bas que ce que l'on peut obtenir dans les versions récentes de Windows (8.0 et versions ultérieures), ou si ces API ont été silencieusement converties pour s'asseoir au-dessus d'autres éléments (comme Direct2D, DirectWrite, etc.). Quel est le lien entre les anciennes API et les plus récentes? J'adorerais si vous pouviez clarifier ce peu!

@stakx , je fais référence à USER32 et GDI32.

Je vais vous donner un aperçu rapide de ce que je sais par cœur sans passer des heures à confirmer les détails. En tant que tel, une partie de cela est sujette à un agitation manuelle et pourrait être légèrement incorrecte, mais est probablement dans la bonne direction. Considérez chaque déclaration comme étant ma connaissance personnelle du fonctionnement du monde et sujette à des opinions ou à des erreurs.

Pour la partie graphique du pipeline (GDI32), les parties en mode utilisateur de GDI sont assez éloignées. L'application appelle GDI32, un certain travail est effectué dans cette DLL du côté du mode utilisateur, puis un appel de noyau passe au noyau et le dessin se produit.

La partie que vous pensez à propos de "converti silencieusement pour s'asseoir au-dessus d'autres choses" est probablement qu'une fois que nous avons frappé les appels du noyau, un tas de trucs GDI du noyau a tendance à être re-plateforme sur les mêmes choses que DirectX lorsqu'il est réellement géré par NVIDIA / AMD / Intel / etc. pilote graphique et le GPU en bas de la pile. Je pense que cela s'est produit avec la ré-architecture du pilote graphique qui faisait partie de WDDM pour Windows Vista. Il existe un document quelque part sur les appels qui sont toujours très rapides dans GDI et ceux qui sont plus lents en raison de la remise en forme. La dernière fois que j'ai trouvé ce document et vérifié, nous utilisions les plus rapides.

En plus de GDI, je crois qu'il y a des choses comme les contrôles communs ou comctl32.dll qui fournissaient aux gens des ensembles réutilisables de boutons et d'éléments pour créer leurs interfaces utilisateur avant que nous ayons des cadres déclaratifs plus agréables. Nous ne les utilisons pas vraiment dans la console (sauf dans la feuille de propriétés du menu contextuel).

Quant à DirectWrite et D2D et D3D et DXGI eux-mêmes, ils constituent un ensemble distinct de commandes et de chemins complètement à l'écart de GDI, à la fois en mode utilisateur et en mode noyau. Ils ne sont pas vraiment liés à part le fait qu'il existe des dispositions d'interopérabilité entre les deux. La plupart de nos autres frameworks d'interface utilisateur ont cependant tendance à être construits au-dessus de la pile DirectX. XAML est sûr. Je pense que WPF l'est. Pas sûr de WinForms. Et je pense que la pile de composition et le gestionnaire de fenêtres utilisent également DirectX.

En ce qui concerne la partie entrée / interaction du pipeline (USER32), j'ai tendance à trouver que la plupart des autres éléments plus récents (au moins pour les ordinateurs de bureau) sont construits par-dessus ce qui existe déjà. Le concept principal de USER32 est les fenêtres et les poignées de fenêtre et tout est envoyé à une poignée de fenêtre. Tant que vous êtes sur une machine de bureau (ou un ordinateur portable ou autre ... je veux dire une machine Windows de style classique), il y a une poignée de fenêtre impliquée et des messages flottant et cela signifie que nous parlons de USER32.

La file d'attente des messages de la fenêtre est juste une FIFO directe (plus ou moins) de toute entrée pertinente pour cette fenêtre alors qu'elle est au premier plan + ce qui a été envoyé à la fenêtre par d'autres composants du système.

Les nouvelles technologies et les frameworks tels que XAML et WPF et WinForms ont tendance à recevoir les messages de la file d'attente de messages de la fenêtre d'une manière ou d'une autre, à les traiter et à les transformer en rappels d'événements vers divers objets qu'ils ont provisionnés dans leur monde.

Cependant, les technologies plus récentes qui fonctionnent également sur d'autres plates-formes non-bureautiques telles que XAML ont également la capacité de traiter des éléments d'une pile non USER32 complètement différente. Il y a une pile parallèle distincte à USER32 avec toutes nos nouvelles innovations et réalisations sur la façon dont l'entrée et l'interaction devraient se produire qui ne traitent pas exactement les files d'attente de messagerie classiques et les poignées de fenêtre de la même manière. Il s'agit de toute la famille Core * de choses comme CoreWindow et CoreMessaging. Ils ont également un concept différent de «ce qu'est un utilisateur» qui n'est pas si centré autour de vos fesses dans une chaise roulante devant un écran avec un clavier et une souris sur le bureau.

Maintenant, si vous êtes sur XAML ou sur l'un des autres Frameworks ... toute cette complexité est gérée pour vous. XAML découvre comment utiliser DirectX pour vous et négocie avec le compositeur et le gestionnaire de fenêtres pour obtenir des effets sympas en votre nom. Il détermine s'il faut obtenir vos événements d'entrée depuis USER32 ou Core * ou quoi que ce soit de manière transparente en fonction de votre plate-forme et les piles d'entrée peuvent gérer le stylet, le toucher, le clavier, la souris, etc. de manière unifiée. Il contient des dispositions intégrées pour faire toutes sortes de mondialisation, d'accessibilité, d'interaction d'entrée, etc. qui vous facilitent la vie. Mais vous pouvez choisir d'aller directement au bas niveau et de le gérer vous-même ou de ne pas gérer ce qui ne vous intéresse pas.

L'astuce est que GDI32 et USER32 ont été conçus pour un monde limité avec un ensemble limité de commandes. Les PC de bureau étaient la seule chose qui existait, un seul utilisateur au clavier et à la souris, une sortie graphique simple sur un moniteur VGA. Donc, les utiliser directement au "bas niveau" comme le fait conhost est assez facile. Les nouvelles plates-formes pourraient être utilisées au «bas niveau», mais elles sont des ordres de grandeur plus compliquées car elles représentent désormais tout ce qui s'est passé avec l'informatique personnelle depuis plus de 20 ans, comme différents facteurs de forme, plusieurs utilisateurs actifs, plusieurs adaptateurs graphiques et ainsi de suite et ainsi de suite. Vous avez donc tendance à utiliser un cadre lorsque vous utilisez les nouveaux éléments pour que votre tête n'explose pas. Ils le gèrent pour vous, mais ils en gèrent plus qu'ils ne l'ont jamais fait auparavant, ils sont donc plus lents dans une certaine mesure.

Alors, GDI32 et USER32 sont-ils "inférieurs" aux nouveautés? Sorte de.
Pouvez-vous arriver aussi bas avec les nouveautés? Surtout oui, mais vous ne devriez probablement pas et ne voulez pas.
Le nouveau vit-il sur l'ancien ou l'ancien est-il remplacé par le nouveau? Parfois et / ou partiellement.
Fondamentalement ... c'est comme la réponse à tout logiciel ... "c'est un désastre absolu et si nous reculons tous un moment, nous devrions être étonnés que cela fonctionne du tout." : P

Quoi qu'il en soit, c'est assez de randonnée pour un matin. J'espère que cela a quelque peu répondu à vos questions et vous a donné un peu plus de perspicacité.

J'espère que cela a quelque peu répondu à vos questions et vous a donné un peu plus de perspicacité.

@miniksa , c'est effectivement le cas! Cela a aussi un sens parfait. Merci beaucoup d'avoir pris le temps d'écrire tout cela! : +1:

Je vais clore ce problème pour le moment. Merci pour l'enquête et je suis heureux que vous ayez apprécié l'information.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

ghost picture ghost  ·  3Commentaires

alabuzhev picture alabuzhev  ·  3Commentaires

zadjii-msft picture zadjii-msft  ·  3Commentaires

warpdesign picture warpdesign  ·  3Commentaires

ghvanderweg picture ghvanderweg  ·  3Commentaires