Aufpassen muß man bei Grafikausgaben
* nicht jeder TerminalServer hat eine gute Grafikkarte und er stellt diese auch nicht unbedingt den TerminalUsern zur Verfügung
* und viele/häufige Updates/Zeichenoperationen können den TerminalServer (für den jeweiligen User) lahm legen, also so auslasten, dass er kaum noch was machen kann (ein gutes Beispiel sind die DelphiIDE und FinalBuilder, die das oft genug schaffen)
Das ist so nicht ganz richtig. Die im physikalischen Terminalserver eingebaute Grafikkarte spielt für die Anzeige der Terminalserversitzung eine geringe Rolle. Selbst senn diese z.B. nur 1280x1080 schafft, kann der Client auch z.B. 4k ohne Probleme. Allerdings kann es zu Problemen kommen, wenn die Software explizit und zwingen auf die Hardwarebeschleunigung der Grafikkarte zugreifen will. Ich hatte schon CAD-Anwendungen wo ich für den Betrieb im Terminalserver bestimmte Grafikroutinen von Hardware auf Software umstellen musste (Allerdings sind CAD-Anwendungen auch eher schlecht für den Einsatz auf Terminalservern geeignet).
Native Controls werden über RDP sehr schnell übertragen, das das Zeichnen diese der RDP-Client selbst übernimmt und sie sich somit recht gut komprimieren lassen (im Gegensatz zum Beispiel zu VNC, wo selbst manch ein normales Fenster scheibchenweise beim Verschieben neu aufgebaut wird). Anders sieht das den Controls aus, die z.B. auf den Canvas zeichnen. Diese werden als Bitmap übertragen, was eine Komprimierung schlechter werden lässt. Idealerweise verzichtet man entweder ganz auf diese oder man zeichnet diese komplett im Hintergrund und gibt wie erst bei kompletter Fertigstellung aus. Letzteres wirkt sich aber genauso negativ bei dem Verschieben aus. Zwar versucht der RDP-Client dieses durch Zwischenspeichern vom Bitmaps zu verbinden, was aber nur klappt, wenn die gleiche Bitmap (wobei das auch eine Teilbitmap sein kann), an der gleichen Position unverändert neu gezeichnet wird.