Anwendung in RemoteDesktop (RDP) sehr langsamer Aufbau

[Eppos]

Hallo zusammen,

wir haben unsere Anwendung von Delphi XE5 auf Delphi 11 upgedatet.
Sobald die Anwendung in einer Remotedesktop Sitzung läuft, ist der Maskenaufbau um ca. das 5fache langsamer.
In diesem Zusammenhang wollte ich nachfragen, wer dieses Problem kennt und ob es dafür bereits Lösungsansätze gibt.

Gruß
Eppos

[Papaschlumpf73]

Bei mir läuft Delphi 11.2 zum Test auf Windows 11 über RDP völlig problemlos. Und ich habe auch nur 10 MBit-Upload im Büro. Eigentlich sollte der RDP-Verbindung völlig Wurst sein, welche Anwendung offen ist. Obwohl EMBA mit einem der letzten Updates geschrieben hat, dass Verbesserungen i.V.m. RDP vorgenommen wurden. Was das war, ist jedoch an mir völlig vorbei gegangen.

[Union]

Das kann durchaus passieren, wenn die Anwendung sehr grafiklastig ist, z.b. wegen der Verwendung von VCL-Stilen. Die Verbesserungen bzgl. RDP betrafen die Delphi-IDE, nicht die erstellten Programme.

[Papaschlumpf73]

Dennoch sollten die Anwendungen durch RDP nicht ausgebremst werden. Vielmehr sollten einzelne Bilder bei der Übertragung ausgelassen werden. Wegen Geoblocking sehe ich über meine deutsche 10 MBit-Leitung parallel den ganzen Tag n-tv Livestream über Google-Chrome. Da werden alle Bilder einfach ausgelassen, die nicht durch die Leitung passen. Wenn der Bremsen würde, hätte der Tag 96 Stunden :-)

[Eppos]

Also mit Delphi XE5 war es innerhalb 2 Sekunden aufgebaut.
Jetzt mit Delphi 11, daiert 10 Sekunden.

Die RDP-Sitzung ist lokal auf dem Server und dieses Verhalten habe ich ausschließlich über RDP.
Es geht auch nicht um die IDE sondern um das erstellte Programm.

[Papaschlumpf73]

Im nächsten Schritt würde ich versuchen, allen Schnickschnack der RDP-Verbindung zu deaktivieren: Druckerumleitung, Zwischenablage, Sounds usw.

[Blup]

Das wird vermutlich nichts bringen, da dafür nur Bandbreite benötigt wird, wenn diese Verbindungen auch genutzt werden.

[Bernhard Geyer]

Steht alles auf DoubleBuffer?
Wird Skalierung genutzt (bzw. hat die Anwendung passendes Manifest)?

[TiGü]

Einfach mit einer neuen und halbwegs leeren Applikation mit ein paar Controls drauf testen.
Selbes Programm in XE5 und D11 kompilieren und schauen, ob sich auch hier Unterschiede feststellen lassen.

[himitsu]

Zitat:

Dennoch sollten die Anwendungen durch RDP nicht ausgebremst werden

Doch.

RDP fängt die Zeichenoperationen ab und sendet vorzugsweise sie zum Client.
"dort Label mit dem Text", anstatt die tausenden Pixel

und wenn es viel wird, der Sendepuffer voll läuft, dann hängt es nunmal.


VNC, TeamViewer und Co. machen einen Screenshot und zwischen den Schüssen kann alles ungehindert laufen ... nur das Senden hängt bei zuviel veränderten Pixeln dann etwas in der Übertragung.


Beim Füllen von Listen/Grids kann man mit BeginUpdate, DisableControls und Dergleichen arbeiten.
Und wenn die GUI größtenteils eh selbst gemalt wird (Skins, Grids usw.), dann könnte man es mal mit DoubleBuffered versuchen.
(hat man DevExpress, dann hängt sich der Dreck eh überall in die Form und schaltet überall zwanghaft das Doublebuffered ein, ohne daß man sich wehren kann, auch bei Controls, die garnicht zu ihm gehören)

[Rolf Frei]

Das ist hier doch alles Symptombekämpfung. Die Frage ist, was bei der XE5 App anders ist, als in der D11 App. Nutzt du Styles? Hat die XE5 Version keine Styles aktiviert und nutz damit das nativen Windowpainting der Controls? Ist in de D11 App ein unbeabsichtigtes Style aktiv, das nun zu massivem Painting der Oberfläche führt. Ist in D11 die Option "Enable Runtime Themes" aktiviert und bei XE5 nicht?

[Eppos]

Alles steht auf DoubleBufferes.
Ich nutze Styles von TMS.
Laufzeit-Themes sind aktiviert.
DPI-Unterstützung steht auf keiner.
Ausfürhungseben auf Als Aufrufer.

[Rolf Frei]

Dann deaktiviere doch mal die Runtime Themes und schau, ob das was verändert.

[Eppos]

Die Laufzeit Themes waren es, ich konnte es aber nicht deaktivieren. Nach dem speichern war der Haken immer wieder drin.

Jetzt sieht natürlich die Anwednung total furchtbar aus, mich interessiert eher, warum man hier einen Rückschrit gemacht hat.

[Eppos]

Wenn ich das deaktiviere, spinnt alles. Es werden sogar Eigenschaften aus den DFMs komplett entfernt.
Beispiel: DropDownCount = 20

[Rolf Frei]

Die Einstellung "Enable Runtime Themes" unter Applikation/Manifest solltet du eingeschalten lassen, sonst spinnt da so einiges, weil die IDE mit aktivierten Themes läuft und dann bestimmte Sachen nicht mehr richtig geladen/gespeichert werden (DFM -> z.b. Imagelisten). Sorry, das ist garnicht die Einstellung, die ich gemeint habe. Ich meinte, ob die Delphi Styles aktiviert sind oder nicht. Das ist unter Application/Appearance zu finden. Da solltest du den Dafault Style auf "Windows" stehen haben. Damit wird der Windows Theme Support verwednet und nicht der Delphi Style Support, der eventuell für dein Verhalten zuständig ist. Wenn du da unter Customstyles nichts ausgewählt hast, sollte der Delphi Style nicht zum Einsatz kommen.

Sorry, dass ich dich hier fehlgeleitet habe. Unter Manifest muss "Enable Runtime Themes" auf jeden Fall aktiv sein.

Das Problem könnte aber schon irgendwas mit der automatisch erzeugten Manifest Datei zu tun haben. Gibt da glaube ich auch Einträge für Remotedesktop.

Versuch auch mal folgende Zeile im DPR direkt nach den Uses einzufügen:

Delphi-Quellcode:

uses
  Controls,
  Classes,
  Forms,
  Windows,  // dieses wird unbedingt benötigt, damit IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE erkannt wird.
  ...;

{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

Ich habe hier mit Remote Desktop und D11 kompilierten Programmen keine Probleme, daher vermute ich, dass das bei dir nicht direkt was mit D11 zu tun hat, sondern eventuell am einem Eintrag der Manifesstdatei liegt, die eventuell hier anders ist als be XE5.

[Eppos]

hat leider kein Unterscheid gebracht.

Styles verwende ich keine.

[Rolf Frei]

Das ist alles sehr komisch. Wie gesagt läuft mein Prorgamm unter RDP ohne Probleme und ich habe da echt keine Idee mehr, was da noch dein Problem sein könnte. Hast du ein eigenes Manifestfile, das du in dein Programm linkst oder verwendest du das von der IDE zur Verfügung gestelte? Hast du das Problem auch mit einer neuen Anwendung?

[Eppos]

Ich verwende das von IDE.

Ich habe ein komplett neues Programm erstellt und eine Maske dort hineinkopiert - ohne Code. Gleiches Problem.
Vermutlich werde ich ein Supportticket bei Emba aufmachen.

[Rolf Frei]

Darf ich noch fragen was für Komponenten du da in deiner Testanwendung drin hast? Ist da evenutell eine 3rd Party Komponente dafür verantwortlich, die unter D11 irgendwas anders macht? Lösch dir doch dann einfach mal Komponente für Komponente raus und teste jeweils, ob sich was verändert hat. Ist das eigentlich eine FMX oder VCL Anwendung? Meine ist eine VCL Anwendung.

Läuft eventuell noch der Firefox parallel im Remode Desktop? Wenn ja, beenden den mal. Der mach bei mir nämlich manchmal auch Probleme, wenn der zu lange läuft oder zu viele Tabs offen hat. Dann werden die Fenster von neu geöffneten Anwendung (beliebige nicht D11 bezogene) auch x-Mal neu gepaintet und alles verlangsamt, bis die Anwenungd richtig geladen ist. Danach ist aber wieder gut. Wenn ich dann den FF beende, ist wieder alles gut und die Anwendungen werden wieder normal geladen, bis das Probmlen dann irgendwann wieder anfängt. Vermutlich hat das aber nichts mit deinem Problem zu tun.

[Eppos]

Ich habe Komponenten von TMS in einer VCL Anwendung.
Bin gerade am ausprobieren, ich glaube es geht tatsächlich in Richtung TMS.

Es läuft nur die Anwendung.

[freimatz]

Komponenten von TMS? Welche? Wir haben die Advanced Controls, Menüband und so. Ich bemerke jedoch eigentlich kein besonderes Problem.

[Eppos]

Die ganz normalen VCL Components. Panels, Edits, etc.
Hier haben wir auch Probleme mit flackern usw.

[Uwe Raabe]

Um mal in einer anderen Richtung zu suchen: Kannst du mal in einer Kommandozeile folgenden Befehl auf beiden Systemen aufrufen und das Ergebnis hier zeigen:

Code:

netsh interface tcp show global

[Eppos]

Entwickler PC:

Globale TCP-Parameter
----------------------------------------------
Zustand der empfangsseitigen Skalierung : enabled
Autom. Abstimmungsgrad Empfangsfenster : normal
Add-On "Überlastungssteuerungsanbieter" : default
ECN-Funktion : disabled
RFC 1323-Zeitstempel : disabled
RTO (anfänglich) : 1000
Zustand der Empfangssegmentzusammenfügung : enabled
Nicht-SACK-RTT-Widerstandsfähigkeit : disabled
Maximale SYN-Neuübertragungen : 4
Fast Open : enabled
Fast Open-Fallback : enabled
HyStart : enabled
Proportionale Ratenreduzierung : enabled
Schrittsteuerungsprofil : off


RDP-Sitzung:

Globale TCP-Parameter
----------------------------------------------
Zustand der empfangsseitigen Skalierung : enabled
Autom. Abstimmungsgrad Empfangsfenster : normal
Add-On "Überlastungssteuerungsanbieter" : default
ECN-Funktion : enabled
RFC 1323-Zeitstempel : disabled
RTO (anfänglich) : 3000
Zustand der Empfangssegmentzusammenfügung : enabled
Nicht-SACK-RTT-Resilienz : disabled
Maximale SYN-Neuübertragungen : 2
Fast Open : disabled
Fast Open-Fallback : enabled
HyStart : enabled
Schrittsteuerungsprofil : off

[Uwe Raabe]

Du könntest mal versuchen, ob es mit diesem Befehl besser wird (auf beiden Rechnern):

Zitat:

netsh interface tcp set global autotuninglevel=disabled

Den vorigen Zustand kannst du mit diesem Befehl wieder herstellen:

Zitat:

netsh interface tcp set global autotuninglevel=normal

Alternative Werte zum Ausprobieren wären noch restricted, highlyrestricted und experimental (mit dem letzten wäre ich vorsichtig)

[Eppos]

Bringt keinen Unterschied.

[Union]

Dann würde ich vorschlagen, dass Du dich an das Problem "herantastest". D.h. Erst eine nackte VCL-Anwendung erstellen, testen, weitere Komponenten einbauen. Irgendwann bricht die Performance ein und Du hast den Schuldigen gefunden.

[Eppos]

Nachdem wir den Emba-Support angeschrieben hatten, haben wir binnen weniger Minuten eine Antwort mit der Problemlösung erhalten.
Diese möchte ich euch nicht vorenthalten:

Delphi-Quellcode:

Application.SingleBufferingInRemoteSessions := false;

[Rolf Frei]

Toll und wo gibt es eine Erklärung, was das genau für Auswirkungen hat und wieso das bei dir Probleme macht und bei uns nicht? Ich würde schon gerner wissen, wieso man diese Flag nun bracht und was da von Emba geändert wurde, dass es dieses Flag nun überhaupt gibt. Sollten wir das in unseren Anwendungen auch ändern, wenn sie im RDP laufen?

[Sherlock]

Na, in der tollen Doku: https://docwiki.embarcadero.com/Libr...RemoteSessions
Du stellst Fragen.

Sherlock

[hoika]

Hallo,
man hätte das auch DoubleBufferingInRemoteSessions nennen können ;)

[Rolf Frei]

Man findet leider niergends eine Info dazu und die nutzlose Hilfe, war wohl eher sarkastisch von dir gemeint. :-)

Das ist alles, was man per Google dazu findet: https://support.tmssoftware.com/t/ta...licker/19141/3

[dummzeuch]

Der damit verbundene Sourcecode ist - hm - "übersichtlich". Es gibt zwei Stellen, in der die Property verwendet wird:

1. TWinControl.CMRemoteSessionStatusChanged
2. TWinControl.SetDoubleBuffered

Wobei ich mit "übersichtlich" nicht unbedingt meine, dass es leicht verständlich ist, denn es wird DoubleBuffered temporär auf False gesetzt, wenn es sich um eine Remote Deskop Session handelt, bzw. auf den vorher gespeicherten Wert, wenn nicht.

Wenn ich das richtig interpretiere bewirkt das einfach nur, dass DoubleBuffered in allen von TWinControl abgeleiteten Controls für RDP zwangsweise False ist. Das bedeutet, dass nicht mehr intern gepuffert wird sondern das dem "Grafiktreiber" der Remote Desktop Session überlassen wird.

[Rolf Frei]

Ja das habe ich selber gesehen, aber es ist mir halt nicht klar, wieso das Double Buffering bei RDP ausgeschaltet wird. Was ist der Grund dafür, dass man das macht?

[dummzeuch]

Zitat:

Zitat von Rolf Frei (Beitrag 1512583)

Ja das habe ich selber gesehen, aber es ist mir halt nicht klar, wieso das Double Buffering bei RDP ausgeschaltet wird. Was ist der Grund dafür, dass man das macht?

Double Buffering sorgt vereinfacht dafür, dass mehrere GDI-Zeichenbefehle zusammengefasst auf eine Bitmap angewendet werden und dann diese Bitmap am Bildschirm angezeigt werden. Das erhöht die Datenmenge bei einer RDP-Session, da eine Bitmap statt der Zeichenbefehle übertragen wird. Lokal reduziert es das Flackern.

[himitsu]

Wenn alles geskinnt (bunt bemalt ist), kann das DB aber auch wieder reduzieren ... ein großes Bitmap, anstatt vieler, tweilweise übereinanderliegender, Kleiner.

[ULIK]

Oh Mann, diese Neuerung hat mich hier jetzt 1 Woche Arbeit gekostet, um herauszufinden, warum Zeichenoperationen die Anwendung auf einmal wie flackern lassen, wenn man sie in einer Terminalserversession gestartet hat. :wall:

Eine Bitte an Embarcadero: wäre es möglich, das in der Änderungshistorie deutlicher hervorzuheben? In den Releasenotes von 11.1 findet sich nur eine Zeile dazu, nämlich daß es Qualitätsverbesserungen für RemoteDesktop gegeben hat. That's all.
Immerhin wurde ja an einem durchaus zentralen Property der VCL rumgeschraubt: DoubleBuffered mal eben im Hintergrund zu deaktivieren, find ich irgendwie schon sportlich.

Gibt's da noch irgendwelche Änderungen in Bezug auf RemoteDesktop und dem Anwendungsverhalten, die man nun prüfen sollte?

[himitsu]

Noch mehr Spaß ... DevExpress aktiviert das DoubleBuffered gern, aber nicht nur für seine Komponenten, sondern auch mal für Übergeordnete, bis hoch zur Form, egal ob RDP oder nicht.
So bekämpfen sich dann schonmal VCL und DX. :thumb:

Besonders beschissen ist es, wenn es im FormDesigner passiert und man dann 2 Milliarden Änderungen im commit hat,
jenachdem ob lokal oder im RDP mit Delphi gearbeitet wird, am Besten noch abwechselnd.

Mehrere Entwickler mit unterschiedlichen Monitoren (unterschiedliche DPI und Scalierung), bereiten auch besonders viel Spaß.

[ULIK]

Danke für den Hinweis zu DevExpress. Sollte ich glaub ich auch mal prüfen. Bisher ist mir da zum Glück noch nichts aufgefallen.