Terminal: Das Tippen innerhalb des Standard-WSL-Terminals fühlt sich erstaunlich an. Warum ist es besser als jede andere App?

Erstellt am 14. Dez. 2018  ·  8Kommentare  ·  Quelle: microsoft/terminal

Entschuldigung, dies ist kein Problem, aber es ist eher ein Vorschlag / eine Aufforderung, nicht zu brechen, was auch immer Sie getan haben, da das Standard-WSL-Terminal (speziell Ubuntu) so schnell reagiert, wenn es darum geht, Zeichen auf dem Bildschirm nach dem Drücken von a zu rendern Schlüssel.

Wenn Sie das Standard-WSL-Terminal eingeben, fühlen Sie sich, als würden Sie auf Sendung tippen. Es gibt eine Glätte, die in keiner anderen Windows-App vorhanden ist, nicht einmal notepad.exe . Wenn es sich so anfühlt, als hätte es 10 ms Eingangsverzögerung anstelle von 75 ms + für alle anderen Windows (und 200-250 ms + für die meisten elektronenbasierten Apps).

Was macht das WSL-Terminal besser als notepad.exe und wird diese UI-Verbesserung in Zukunft auch für alle Windows-Apps verfügbar sein?

Fühlen Sie sich frei, dies zu schließen, wenn Sie nicht darüber diskutieren möchten. Ich habe es hauptsächlich geöffnet, um ein Bewusstsein dafür zu schaffen, wie gut es ist, hoffentlich zu verhindern, dass es in Zukunft zu einer Regression kommt.

Issue-Question Product-Conhost

Hilfreichster Kommentar

Es macht mir wirklich nichts aus, wenn jemand vorbeikommt und beschließt, uns zu sagen, dass wir in etwas gute Arbeit leisten. Wir hören jeden Tag so viele Beschwerden, dass ein Beitrag wie dieser ein Hauch frischer Luft ist. Danke für deinen Dank!

Gerne bespreche ich dies auch mit Ihnen, bis Sie es satt haben, es zu lesen. Bitte fragen Sie nach den gewünschten Follow-Ons. Ich lebe davon, über meine Arbeit zu plappern. : P.

Wenn ich eine fundierte Vermutung anstellen müsste, was uns schneller macht als so ziemlich jede andere Anwendung unter Windows, wenn es darum geht, Ihren Text auf den Bildschirm zu bringen ... Ich würde sagen, das liegt buchstäblich daran, dass dies buchstäblich unser einziger Job ist! Wahrscheinlich auch, weil wir verdammt nahe an den ältesten und niedrigsten APIs arbeiten, die Windows benötigt, um diese Arbeit auszuführen.

Bei so ziemlich allem, was Sie aufgelistet haben, handelt es sich um eine Ebene oder ein Framework oder um viele, viele Ebenen und Frameworks, wenn Sie über Electron und Javascript sprechen. Wir nicht.

Wir haben ein nacktes, super ungewöhnliches Fenster ohne zusätzliche Steuerelemente. Wir erhalten unsere Schlüssel von knapp über dem Kernel, da wir sie aus Fenstermeldungen verarbeiten und nicht aus einem Ereignis-Framework, das so ziemlich jedem anderen komplizierteren UI-Framework als unserem (WPF, WinForms, UWP, Elektron). Und wir werfen unseren Text mit GDIs PolyTextOut ohne Schnickschnack direkt auf die Fensteroberfläche.

Sogar notepad.exe hat mindestens mehrere Steuerelemente in seinem Fenster und verwendet wahrscheinlich (ich habe nicht nachgesehen) eine Art Bibliotheksframework im Bearbeitungssteuerelement, um das Textlayout herauszufinden (das wahrscheinlich eine andere Bibliothek verwendet) Rahmen für die Unterstützung der Internationalisierung ...)

Das bedeutet natürlich auch, dass wir Kompromisse haben. Wir unterstützen nicht vollständig internationalen Text wie so ziemlich jede andere Anwendung. RTL? Momentan keine Go-Zone. Ersatzpaare und Emoji? Wir kommen dorthin, aber noch nicht da. Indische Skripte? Nee.

Warum sind wir so? Zum einen ist conhost.exe alt wie Dreck. Es muss die Bare-Metal-Bodenschicht von allem verwenden, da es erstellt wurde, bevor die meisten dieser anderen Frameworks erstellt wurden. Und es wird so niedrig wie möglich gehalten, da es so ziemlich das erste ist, was man beim Aufrufen einer neuen Betriebssystemversion oder eines neuen Geräts ansprechen muss, bevor man all die netten Dinge wie Frameworks oder die Anforderungen dieser Frameworks hat arbeiten. Außerdem ist es in C / C ++ geschrieben, was ungefähr so ​​niedrig und blank wie möglich ist.

Wird diese Verbesserung der Benutzeroberfläche auch für andere Apps unter Windows verfügbar sein? Mit ziemlicher Sicherheit nicht. Sie haben zu viel los, was sowohl gut als auch schlecht ist. Ich bin neidisch auf ihre Fähigkeit, nur eine Methode und einen Layouttext unkompliziert in einer beliebigen Sprache aufzurufen, ohne die Pixel manuell zu berechnen oder sich darum zu kümmern, welche Stile für ihre Schriftart gelten. Aber meine manuellen Pixelberechnungen, die schmutzige Regionsmathematik, der Wahnsinn der Scrollregionen und vieles mehr machen es so, dass wir schneller als sie gehen. Ich bin auch eifersüchtig, dass jemand, der sagt "Hey, können Sie eine Statusleiste am unteren Rand Ihres Fensters hinzufügen?" war für immer ein Rückstand und gibt mir Sodbrennen, wenn ich über die Implementierung nachdenke.

Werden wir versuchen, eine Rückbildung zu verhindern? Ja! Im Moment ist es eine Art manueller Prozess. Wir stellen fest, dass etwas langsam wird, und holen dann WPR heraus und beginnen, Spuren zu

Abgesehen davon möchte

Wenn Sie noch etwas wissen möchten, lassen Sie es mich wissen. Ich könnte den ganzen Tag weitermachen. Ich habe wie 15 Tangenten aus dieser Antwort gelöscht, bevor ich sie gepostet habe ....

Alle 8 Kommentare

Es macht mir wirklich nichts aus, wenn jemand vorbeikommt und beschließt, uns zu sagen, dass wir in etwas gute Arbeit leisten. Wir hören jeden Tag so viele Beschwerden, dass ein Beitrag wie dieser ein Hauch frischer Luft ist. Danke für deinen Dank!

Gerne bespreche ich dies auch mit Ihnen, bis Sie es satt haben, es zu lesen. Bitte fragen Sie nach den gewünschten Follow-Ons. Ich lebe davon, über meine Arbeit zu plappern. : P.

Wenn ich eine fundierte Vermutung anstellen müsste, was uns schneller macht als so ziemlich jede andere Anwendung unter Windows, wenn es darum geht, Ihren Text auf den Bildschirm zu bringen ... Ich würde sagen, das liegt buchstäblich daran, dass dies buchstäblich unser einziger Job ist! Wahrscheinlich auch, weil wir verdammt nahe an den ältesten und niedrigsten APIs arbeiten, die Windows benötigt, um diese Arbeit auszuführen.

Bei so ziemlich allem, was Sie aufgelistet haben, handelt es sich um eine Ebene oder ein Framework oder um viele, viele Ebenen und Frameworks, wenn Sie über Electron und Javascript sprechen. Wir nicht.

Wir haben ein nacktes, super ungewöhnliches Fenster ohne zusätzliche Steuerelemente. Wir erhalten unsere Schlüssel von knapp über dem Kernel, da wir sie aus Fenstermeldungen verarbeiten und nicht aus einem Ereignis-Framework, das so ziemlich jedem anderen komplizierteren UI-Framework als unserem (WPF, WinForms, UWP, Elektron). Und wir werfen unseren Text mit GDIs PolyTextOut ohne Schnickschnack direkt auf die Fensteroberfläche.

Sogar notepad.exe hat mindestens mehrere Steuerelemente in seinem Fenster und verwendet wahrscheinlich (ich habe nicht nachgesehen) eine Art Bibliotheksframework im Bearbeitungssteuerelement, um das Textlayout herauszufinden (das wahrscheinlich eine andere Bibliothek verwendet) Rahmen für die Unterstützung der Internationalisierung ...)

Das bedeutet natürlich auch, dass wir Kompromisse haben. Wir unterstützen nicht vollständig internationalen Text wie so ziemlich jede andere Anwendung. RTL? Momentan keine Go-Zone. Ersatzpaare und Emoji? Wir kommen dorthin, aber noch nicht da. Indische Skripte? Nee.

Warum sind wir so? Zum einen ist conhost.exe alt wie Dreck. Es muss die Bare-Metal-Bodenschicht von allem verwenden, da es erstellt wurde, bevor die meisten dieser anderen Frameworks erstellt wurden. Und es wird so niedrig wie möglich gehalten, da es so ziemlich das erste ist, was man beim Aufrufen einer neuen Betriebssystemversion oder eines neuen Geräts ansprechen muss, bevor man all die netten Dinge wie Frameworks oder die Anforderungen dieser Frameworks hat arbeiten. Außerdem ist es in C / C ++ geschrieben, was ungefähr so ​​niedrig und blank wie möglich ist.

Wird diese Verbesserung der Benutzeroberfläche auch für andere Apps unter Windows verfügbar sein? Mit ziemlicher Sicherheit nicht. Sie haben zu viel los, was sowohl gut als auch schlecht ist. Ich bin neidisch auf ihre Fähigkeit, nur eine Methode und einen Layouttext unkompliziert in einer beliebigen Sprache aufzurufen, ohne die Pixel manuell zu berechnen oder sich darum zu kümmern, welche Stile für ihre Schriftart gelten. Aber meine manuellen Pixelberechnungen, die schmutzige Regionsmathematik, der Wahnsinn der Scrollregionen und vieles mehr machen es so, dass wir schneller als sie gehen. Ich bin auch eifersüchtig, dass jemand, der sagt "Hey, können Sie eine Statusleiste am unteren Rand Ihres Fensters hinzufügen?" war für immer ein Rückstand und gibt mir Sodbrennen, wenn ich über die Implementierung nachdenke.

Werden wir versuchen, eine Rückbildung zu verhindern? Ja! Im Moment ist es eine Art manueller Prozess. Wir stellen fest, dass etwas langsam wird, und holen dann WPR heraus und beginnen, Spuren zu

Abgesehen davon möchte

Wenn Sie noch etwas wissen möchten, lassen Sie es mich wissen. Ich könnte den ganzen Tag weitermachen. Ich habe wie 15 Tangenten aus dieser Antwort gelöscht, bevor ich sie gepostet habe ....

In Bezug auf Windows-APIs auf niedriger Ebene stellte ich fest, dass alle _user mode_-Komponenten sowohl der Konsole (conhost.exe, cmd.exe ...) als auch der WSL (wsl.exe, LxssManager.dll ...) C ++ _STL_ enorm verwenden. Zum Beispiel bei der Manipulation von Zeichenfolgen, der Speicherzuweisung, virtuellen Tabellen usw. Gibt es eine Leistungsverbesserung, wenn nur C verwendet wird?

Ich würde diese nicht als "enorm" betrachten, wenn man C ++ STL verwendet. Sie verwenden definitiv einige der Sammlungen und vielleicht ein bisschen String-Manipulation und einen Algorithmus hier oder da. Ich habe das Gefühl, dass STL viel mehr beinhaltet als diese wenigen Teile.

Aber trotzdem ... die meisten Dinge, die Sie beschreiben, wurden vor einiger Zeit direkt in C geschrieben. Wir haben C ++ und STL in immer mehr von ihnen als bewussten Kompromiss selektiv eingesetzt. Solange wir genau wissen, was die Vorlagen unter der Haube tun, und die richtigen sorgfältig verwenden, handeln wir im Allgemeinen nur mit einer sehr geringen Leistung und gewinnen gleichzeitig ein erhebliches Maß an Sicherheit und Programmierfreundlichkeit.

Sicherheit ist eigentlich der Hauptgrund, warum wir STL-Vorlagen verwenden, um zu versuchen, wann immer möglich unsere eigenen Strukturen zu erstellen. Die Verwendung der STL-Vorlagen für Sammlungen und Zeichenfolgen ermöglicht uns im Allgemeinen die Überprüfung von Grenzen, die andernfalls fehleranfällig (oder gar nicht!) Manuell durchgeführt werden müssten.

Ich bin mir auch nicht ganz sicher, ob 17 verschiedene Implementierungen von Warteschlangen und verknüpften Listen im Konsolencode, als es gerade C war, insgesamt besser für die Leistung waren als die Verwendung von std :: queue und std :: list heute. Es hat wahrscheinlich mehr Speicherplatz auf der Festplatte für jede einzelne Implementierung verbraucht, was eine andere Art von Leistungsproblem darstellt (Speicher und E / A zum Laden von Seiten).

Vielen Dank, dass Sie sich die Zeit genommen haben, diese Antwort zu schreiben, und kein Problem mit dem Lob.

In den letzten paar Monaten habe ich nach einem guten Terminal-Setup gesucht, und ich denke, dass ubuntu.exe mit tmux so perfekt ist, wie Sie es mit den Tools, die wir heute haben, erreichen können. Das ubuntu.exe -Terminal selbst ist blitzschnell und tmux bietet Ihnen alle lebenslangen Qualifikationen (Registerkarten, geteilte Fenster, Puffersuche usw.).

Ich freue mich sehr auf zukünftige Versionen, die Farbthemen kompatibler machen und auf Eigenschaften bezogene Verbesserungen wie Hotkeys zum Zoomen von +/- auf die Schriftgröße.

@miniksa : Danke für einen sehr interessanten Beitrag!

Wir verwenden verdammt nahe der ältesten und niedrigsten APIs, die Windows benötigt, um diese Arbeit auszuführen.

Ich war eine Weile neugierig darauf. Sie scheinen sich auf die verschiedenen Win32-APIs (USER32 / GDI32) zu beziehen. Ich bin mir in letzter Zeit nicht sicher, ob sie immer noch so niedrig sind wie in neueren Windows-Versionen (8.0 und höher) oder ob diese APIs stillschweigend konvertiert wurden, um auf anderen Dingen (wie Direct2D) zu sitzen. DirectWrite usw.). In welcher Beziehung stehen die älteren APIs zu den neueren? Ich würde es lieben, wenn Sie dieses bisschen klären könnten!

@stakx , ich beziehe mich auf USER32 und GDI32.

Ich gebe Ihnen einen flüchtigen Überblick über das, was ich auf den ersten Blick weiß, ohne Stunden damit zu verbringen, die Details zu bestätigen. Als solches unterliegt ein Teil davon dem Handwinken und könnte leicht falsch sein, ist aber wahrscheinlich in die richtige Richtung. Betrachten Sie jede Aussage als mein persönliches Wissen darüber, wie die Welt funktioniert und ob sie einer Meinung oder einem Fehler unterliegt.

Für den Grafikteil der Pipeline (GDI32) sind die Benutzermodus-Teile von GDI ziemlich weit unten. Die App ruft GDI32 auf, einige Arbeiten werden in dieser DLL auf der Seite des Benutzermodus ausgeführt, dann springt ein Kernelaufruf zum Kernel und das Zeichnen erfolgt.

Der Teil, den Sie in Bezug auf "stillschweigend konvertiert, um auf anderen Dingen zu sitzen" in Betracht ziehen, ist wahrscheinlich, dass, sobald wir die Kernel-Aufrufe getroffen haben, ein Haufen der Kernel-GDI-Dinge dazu neigt, auf denselben Dingen wie neu zu plattformieren DirectX, wenn es tatsächlich von NVIDIA / AMD / Intel / etc. Verwaltet wird. Grafiktreiber und die GPU am unteren Rand des Stapels. Ich denke, dies geschah mit der Neuarchitektur des Grafiktreibers, die als Teil von WDDM für Windows Vista geliefert wurde. Irgendwo gibt es ein Dokument darüber, welche Anrufe in GDI immer noch sehr schnell sind und welche aufgrund der Neuplattformierung langsamer sind. Als ich das letzte Mal dieses Dokument gefunden und überprüft habe, haben wir die schnellen verwendet.

Zusätzlich zu GDI gibt es meiner Meinung nach Dinge wie Common Controls oder comctl32.dll, die den Leuten wiederverwendbare Sätze von Schaltflächen und Elementen zur Verfügung stellten, um ihre Benutzeroberflächen zu erstellen, bevor wir schönere deklarative Frameworks hatten. Wir verwenden diese nicht wirklich in der Konsole (außer im Eigenschaftenblatt des Rechtsklick-Menüs).

DirectWrite und D2D sowie D3D und DXGI selbst sind separate Befehle und Pfade, die sowohl im Benutzer- als auch im Kernelmodus vollständig von GDI abweichen. Sie sind nicht wirklich verwandt, außer dass es einige Interoperabilitätsbestimmungen zwischen den beiden gibt. Die meisten unserer anderen UI-Frameworks basieren jedoch in der Regel auf dem DirectX-Stack. XAML ist sicher. Ich denke, WPF ist. Ich bin mir bei WinForms nicht sicher. Und ich glaube, dass der Kompositionsstapel und der Fenstermanager auch DirectX verwenden.

Was den Eingabe- / Interaktionsteil der Pipeline (USER32) betrifft, finde ich, dass die meisten anderen neueren Dinge (zumindest für Desktop-PCs) auf dem aufbauen, was bereits vorhanden ist. Das Hauptkonzept von USER32 sind Fenster und Fenstergriffe, und alles wird an einen Fenstergriff gesendet. Solange Sie sich auf einem Desktop-Computer befinden (oder auf einem Laptop oder was auch immer ... ich meine einen Windows-Computer im klassischen Stil), sind ein Fenstergriff und Nachrichten im Umlauf, und das bedeutet, dass es sich um USER32 handelt.

Die Fenstermeldungswarteschlange ist nur ein direktes FIFO (mehr oder weniger) der für dieses Fenster relevanten Eingaben, während sie sich im Vordergrund befinden + was auch immer von anderen Komponenten im System an das Fenster gesendet wurde.

Die neueren Technologien und Frameworks wie XAML, WPF und WinForms empfangen die Nachrichten in der Regel auf die eine oder andere Weise aus der Fenstermeldungswarteschlange und verarbeiten sie und verwandeln sie in Ereignisrückrufe für verschiedene Objekte, die sie in ihrer Welt bereitgestellt haben.

Die neueren Technologien, die auch auf anderen Nicht-Desktop-Plattformen wie XAML funktionieren, können jedoch in der Regel auch Daten von einem völlig anderen Nicht-USER32-Stack verarbeiten. Es gibt einen separaten parallelen Stapel zu USER32 mit all unseren neuen Innovationen und Erkenntnissen darüber, wie Eingaben und Interaktionen erfolgen sollen, der nicht genau mit klassischen Messaging-Warteschlangen und Fensterhandles gleich umgeht. Dies ist die gesamte Core * -Familie von Dingen wie CoreWindow und CoreMessaging. Sie haben auch ein anderes Konzept von "Was ist ein Benutzer", das nicht so zentriert um Ihren Hintern im Rollstuhl vor einem Bildschirm mit einer Tastatur und einer Maus auf dem Schreibtisch ist.

Wenn Sie XAML oder eines der anderen Frameworks verwenden, wird all diese Komplexität für Sie erledigt. XAML findet heraus, wie Sie für Sie auf DirectX zurückgreifen können, und verhandelt mit dem Compositor und dem Fenstermanager über coole Effekte für Sie. Es wird herausgefunden, ob Ihre Eingabeereignisse von USER32 oder Core * oder was auch immer transparent abgerufen werden sollen, abhängig von Ihrer Plattform und den Eingabestapeln, die Stift, Berührung, Tastatur, Maus usw. auf einheitliche Weise verarbeiten können. Es enthält Bestimmungen, die alle Arten von Globalisierung, Zugänglichkeit, Interaktion mit Eingaben usw. ausführen, die Ihnen das Leben erleichtern. Sie können aber auch direkt auf die niedrige Ebene gehen und sich selbst darum kümmern oder die Bearbeitung überspringen, was Ihnen egal ist.

Der Trick ist, dass GDI32 und USER32 für eine begrenzte Welt mit einem begrenzten Satz von Befehlen entwickelt wurden. Desktop-PCs waren das einzige, was es gab, Einzelbenutzer an Tastatur und Maus, einfache Grafikausgabe auf einem VGA-Monitor. Es ist also ziemlich einfach, sie direkt auf der "niedrigen Ebene" zu verwenden, wie es Conhost tut. Die neuen Plattformen könnten auf "niedrigem Niveau" eingesetzt werden, sind jedoch um Größenordnungen komplizierter, da sie jetzt alles berücksichtigen, was in mehr als 20 Jahren mit Personal Computing geschehen ist, wie verschiedene Formfaktoren, mehrere aktive Benutzer, mehrere Grafikadapter, und weiter und weiter und weiter und weiter. Daher tendieren Sie dazu, ein Framework zu verwenden, wenn Sie das neue Material verwenden, damit Ihr Kopf nicht explodiert. Sie erledigen das für Sie, aber sie erledigen mehr als je zuvor, sodass sie bis zu einem gewissen Grad langsamer sind.

Sind GDI32 und USER32 also "niedriger" als die neuen Produkte? Art von.
Kannst du mit den neueren Sachen so niedrig werden? Meistens ja, aber du solltest und willst es wahrscheinlich nicht.
Lebt das Neue über dem Alten oder wird das Alte auf das Neue umgestaltet? Manchmal und / oder teilweise.
Im Grunde ... ist es wie die Antwort auf alles, was mit Software zu tun hat ... "Es ist eine absolute Katastrophe, und wenn wir alle einen Moment zurücktreten, sollten wir uns wundern, dass es überhaupt funktioniert." : P.

Jedenfalls ist das genug für einen Morgen. Hoffentlich hat das Ihre Fragen etwas beantwortet und Ihnen ein bisschen mehr Einblick gegeben.

Hoffentlich hat das Ihre Fragen etwas beantwortet und Ihnen ein bisschen mehr Einblick gegeben.

@ Miniksa , das hat es tatsächlich getan! Sinnvoll auch. Vielen Dank, dass Sie sich die Zeit genommen haben, das alles aufzuschreiben! : +1:

Ich werde dieses Problem vorerst schließen. Vielen Dank für die Anfrage und ich bin froh, dass Ihnen die Informationen gefallen haben.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen