Anwendung in RemoteDesktop (RDP) sehr langsamer Aufbau

[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 von 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?

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.

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.

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.

[himitsu]

Es passiert leider auch nicht immer, jedenfalls nicht nachvollziehbar, aber ab und an ist in DFMs, die in der IDE offen waren, urplötzlich bei fast allen Komponenten das DoubleBuffered auf True, wenn DevExpress-Komponenten auf der Form liegen,
und im Gegenzug ist manchmal das urplötzlich wieder False und fliegt somit wieder aus der DFM raus.



Hab hier immernoch nicht den Umstieg auf D11 fertig, also durch alle Instanzen durch.
Spaß ist nun, dass Delphi 11 nun das OldCreateOrder entfernt hat, also beim Speichern im Designer fliegt es raus.
Dann kommt XE, sieht, dass kein OldCreateOrder existiert und schmeißt es fälschlich mit True in die DFM wieder rein.

Auch schon, weil sich Embarcadero weigert einen Bug zu beheben, welche durch FormVererbung entsteht und wo ich ihnen auch direkt die Lösung nannte. (einfach nur in zwei Settern eine Variable auf 0 setzen),
haben wir schon pervers im Designer den DFM-Reader gehookt.
Da der Hook schon da war, ließ sich nun erstmal einfügen, dass im XE das OldCreateOrder mit False initialisiert wird, falls es aus der DFM rausflog, sowie dass D11 nicht knallt, wenn soein Property dort geladen wird.

https://www.delphipraxis.net/207137-...entheight.html
https://www.delphipraxis.net/211768-...d-kleiner.html





Bezüglich dem DoubleBuffered.
Wenn der Designer es aktiviert, weil Delphi mal im RDP läuft,
dann dürfen solche Änderungen niemals in der DFM landen.

Bei anderen Entwicklern, welche lokal arbeiten, und vor allem im Compilat/Programm, darf soeine Änderung ja niemals enthalten sein.
-> wäre ja fatal, wenn DoubleBuffered dort deaktiviert wäre, wo es eigentlich aktiv sein sollte ... und andersrum.