Also dass der Windows-Explorer langsam ist, kann u.U. an Netzwerkzugriffen oder sonstigen Auslastungen sein. Dazu gehören auch Vorschauen o.ä.
Nun, um "Windows" darzustellen, bedarf es eben sog. Fenster, daher der Name.
EIn Fenster ist ein Objekt im grafischen Umfeld. Hierfür gibt es zahlreiche native Kernel-Funktionen, die sogenannte GDI = Grafical Device Interface.
Jede Bitmap, jedes Icon, jedes Textfeld, Dropdownbox usw., jedes Steuerelement, wurde native durch Windows unterstützt.
Diese hatte den charmanten Vorteil, dass jeder Treiber, der diese Befehle unterstützt, kompatibel dazu ist. Somit kann ich sowohl Fenster ausgeben
als auch drucken.
Welche Möglichkeiten der GDI-Befehle zur Verfügung stehen wird vom Device-Driver abgefragt.
https://de.wikipedia.org/wiki/Graphics_Device_Interface
Hinzu kommt noch ein interessantes Clipping-Verfahren, dass automatisch nicht eingeschlossene Bereiche nicht überschreibt. Wenn ich also ein kleines Rechteck zeichne und dann außerhalb dieses Rechteckes zeichne, hat dies keinen Effekt.
Wenn nun ein Fenster ein anderes überlagert, erzeugt Windows eine Clipregion. Wenn das Fenster dann verschoben wird, kann Windows diesen Teil des Fenstern selbstständig neu zeichnen ohne dass die Anwendung aktiv wird. Somit ließ sich auch sehr einfach Zoom
und Scroll realisieren ohne ständig neuzeichnen zu müssen. Man verschob einfach den "Viewport" und das Bild wurde verschoben.
Nun werden die Ansprüche an die Ausgabe halt immer komplexer und somit gab es neue Möglichkeiten:
GDI+ erlaubt ein paar mehr Funktionen wie Farbverlauf, Transparent o.ä.
https://de.wikipedia.org/wiki/GDI%2B
Hinzu am auch die sog. "Windowless"-Darstellung, also Fenster ohne eigentlich Fenster zu erstellen.
Nun stellt RDP eine virtuelle Grafikarte zur Verfügung, die die GDI/+-Befehle einfach an den Client routed und von der dortigen Software an das Fenster der Sitzung über das dortige GDI an die Grafikkarte weitergeleitet wird.
Da nun GDI für die meisten grafischen Anwendungen nicht mehr ausreichte, wurde DirectX sowie OpenGL entwickelt.
https://de.wikipedia.org/wiki/DirectX
https://de.wikipedia.org/wiki/OpenGL
Dies sind nun Bibliotheken, deren Schnittstellen erheblich mehr Möglichkeiten bieten und vor allem, direkt von der Hardware, also der Grafikkarte unterstützt werden.
Somit können viel mehr Möglichkeiten visualisiert werden. Da eine Grafikkarte aus z.T. mehreren 1000 Prozessoren bestehen, lassen sich eben viele Bilder parallel berechnen. Da werden dann Texturen und 3D-Effekte realisiert. Die Grafikkarte baut dann eine Bitmap
auf, die dann direkt an den Bildschirm übertragen werden kann.
Durch den übergroßen Speicher lassen sich eben mehrere Bilder parallel oder sehr schnell hintereinander berechnen, so dass Filme entstehen können (25Bilder/Sekunde).
Nun sind diese Bibliotheken allerdings so gestrickt, dass Funktionen, die nicht durch die Grafikkarte selber aufgelöst werden, dann in viele Einzelbefehle von der CPU zerlegt werden um sie dann an die Grafikkarte zu übertragen. Beispiel Polygon (Vielfacheck):
Ich kann eine Liste der Koordinaten aller Punkte senden oder jeden einzelnen Zeichenbefehl von Punkt zu Punkt. Ersteres geht schneller, letzteres passiert durch die CPU.
Gleichzeitig bringen die Runtimelibs nun ihre eigenen Steuerelemente, die eben komplexe Zeichnungen ermöglichen. Somit gibt es u.U. auch keine einfache Textbox mehr. Das Zeichen der Tastatur geht an die aktive Anwendung und diese errechnet nun das Layout
um die Textbox darzustellen. Buttons, Dropdownlisten, Grid u.v.m. bestehen zu großen Teilen nur noch aus Zeichenfunktionen (also zeichnen).
Da das Clipping nun zu aufwenig geworden ist, bekommt eine Anwendung bei Überlagerungen von Fenstern nur noch den Befehl, sich neu zu zeichnen. Und dies geht (wie bereits beschreiben), bottom-up, also erst der Hintergrund dann Bilder, dann Schaltflächen und
zum Schluss ggf. Eingabefelder.
Nun ist aber RDP eine Software, die nur eine virtuelle Grafikkarte ohne eigenen Prozessor emuliert. D.h., alle Funktionen der GDI/DirectX/OpenGL müssen von RDP-Server ausgeführt werden und dies kostet nun mal Rechenleistung bevor auch nur 1 Bild übertragen
ist.
Und Bilder sind nun mal Bitmaps.
Du hast recht, dass RDP Bitmaps cachen kann. Dies sind allerdings z.B. feste Symbole oder kleine Bilder auf Schaltflächen o.ä.
Nun nimm aber mal das Ribboncontrol. Hier gibt es auch viele Bilder/Icons usw., allerdings werden gleichzeitig auch Zustände angezeigt. Mit jeder Cursorbewegung im Text kann sich Schrift, Zeichensetzung oder sonstige Formate ändern, Icons sind aktiv oder passiv
oder ändern ihre Darstellung beim Mousehover. Das Ribbon wird also ständig neu gezeichent. Und dafür reicht GDI+ schon länger nicht mehr aus.
Somit wird von Office eben alles über DirectX als Bitmap gezeichnet, und da der gesamte Bildschirm u.U. als ganze Bitmap fungiert, kann RDP da nichts cachen, was sich nun mal in der Performance auswirkt.
Andere Anwendungsframeworks, wie z.B. WPF sind ebenso stark grafikintensiv.
Nun zu RemoteFX und vGPU.
Die virtuelle Grafical Processing Unit ist ein Treiber der Virtualisierung (HyperV, VM-Ware, Virtual Box), die eine Verbindung zur physischen Grafikkarte herstellt. Dies geht nun mal nicht mit dem nativen Treiber, da virtualisierte Hardware nicht im Direktzugriff
einer VM ist, was aber der originale Treiber will.
Hinzu kommt, dass die Grafikkarte auch noch über mehrere VM's und bei Terminalservern mehrere User geteilt werden muss.
RemoteFX klinkt sich nun in die RDP-Sitzung als virtuelle Grafikkarte ein und kann DirektX/OpenGL an die Grafikkarte weiterleiten, bekommt das gerenderte Ergebnis zurück und stellt es als Bitmap dem RDP-Client zur Verfügung. Hierbei kommt auch die Komprimierung
zum Tragen.
Software, die nur GDI/+ verwendet profitiert davon nicht, da diese Befehle ja an den Client direkt gehen können.
Der Wechsel bei Office von GDI+ zu DirectX muss nach Office2010 erfolgt sein. Bis Office 2010 konnte man flott arbeiten, beim Wechsel auf Office 2016 musste ich die Remoteleistung drastisch reduzieren.
