DX10 : FMX: bis zu 7 Sekunden für Umschalten der Ansichten Code / Design

[Harry Stahl]

Diesen Thread hatte ich zu XE8 aufgemacht:

http://www.delphipraxis.net/186191-x...de-design.html

Meine Meldung bei Quality Central hat man zwar aufgegriffen, so dass in DX10 Seattle der Wechsel im konkreten Fall "nur" noch 6,5 statt 11 Sekunden dauert.

Aber auch 6,5 Sekunden sind eindeutig zu viel und stört der Arbeitsfluss enorm (zur Erinnerung: in XE7 dauert das bei der gleichen Form nur 1 Sekunde!!). Auch habe ich den Eindruck dass z.B. der Designer in umfangreicheren FMX-Projekte immer leicht verzögert reagiert, das macht wenig Spaß.

Hat jemand vergleichbare Erfahrungen gemacht? Also es geht um FMX-Projekte, mit recht vielen Komponenten in der Form. Könnt Ihr selbst testen:

C:\Users\Public\Documents\Embarcadero\Studio\17.0\ Samples\Object Pascal\FireMonkey Desktop\ControlsDemo

Hier dauert das umschalten ca. 4 Sekunden.

Würde das noch mal bei QC melden, wäre aber schön, wenn ich da ein wenig Unterstützung hätte (im Sinne einer Bestätigung).

[Der schöne Günther]

Braucht in meiner (relativ lahmen) Virtualbox-VM ca. 3 Sekunden.
Auf XE7.1 (und ohne VM) sind es geschätzt 500ms.

PS: Ich muss unter Win10 mit Seattle aber zugeben dass ich auf den ersten Blick fast nicht mehr sehen konnte dass es hier FireMonkey ist und keine "echten" Komponenten. Nicht übel, da scheint sich ja in den letzten Versionen doch noch einmal ordentlich was getan zu haben :thumb:
Beim nächsten Projekt gebe ich FMX nochmal eine Chance.

[Uwe Raabe]

Zitat:

Zitat von Harry Stahl (Beitrag 1314601)

Hier dauert das umschalten ca. 4 Sekunden.

Hier unter 1 Sekunde - bei XE7 nicht merkbar.

[Bernhard Geyer]

Infos über Grafikkarte wären sinnvoll. Hab mit älteren Intel HD (abseits von fmx) so meine Erfahrungen gemacht

[Harry Stahl]

An der Grafikkarte wird es nicht liegen, dennoch anliegend die Info. Auch wenn der PC schon etwas älter ist, er ist in allem aber recht flott.

Wie gesagt gleicher PC, gleiche Form (die Daten beziehen sich auf meine Form, NICHT auf das ControlsDemo):

XE7: 0,8 Sekunden
XE8: 11,5 Sekunden
DX10: 6,5 Sekunden

Bei der ControlsDemo-Form dauert es hier ca. 3 Sekunden in DX10 (unter XE7 nicht messbar).

Irgendwas wurde von XE7 nach XE8 geändert, das grundsätzlich diese Verlangsamung bewirkt.

Es ist nicht die Geräteübergreifende Ansicht, selbst wenn man die ausschaltet, dauert es so lange.

[Harry Stahl]

Ergänzende Info: Die ControlsDemo-Form hat ca. 152 kB, meine Form hat ca. 650 kB und hat noch ein paar Controls mehr drauf (siehe anliegenden Screenshot).

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1314606)

Zitat:

Zitat von Harry Stahl (Beitrag 1314601)

Hier dauert das umschalten ca. 4 Sekunden.

Hier unter 1 Sekunde - bei XE7 nicht merkbar.

IDEFixPack installiert? Das hat nämlich nen Fix für das langsame Umschalten durch die LiveBindings.

[Harry Stahl]

Zitat:

Zitat von Stevie (Beitrag 1314631)

IDEFixPack installiert? Das hat nämlich nen Fix für das langsame Umschalten durch die LiveBindings.

LiveBindings nutze ich gar nicht. Aber das IDEFixPack (5.93) ist bei mir hier auch in Delphi XE8 installiert (für Delphi DX10 gibt es das ja noch nicht).

Kein Unterschied, ob mit oder ohne IDEFixpack.

[Darlo]

Hi, habe es gerade bei mir getestet. Vergleich zwischen XE7 Update 1, XE8.1 und XE10 Seattle, jeweils Enterprise Edition.
Keine Fixpacks oder sonstiges für die IDE installiert.

Form mit 1.231 Komponenten :duck:
FMX-Datei ist 733 KB groß
Keine Bilder auf der Form

XE7: zeitgleich <0,5 Sek
XE8.1: 3,8 Sek
XE10 Seattle: 2,1 Sek

Also bei mir selbes Ergebnis.

[Stevie]

Bei ner Form mit 1200 Komponenten sollte sich eigentlich die IDE schließen und deinstallieren :duck:

[mkinzler]

Vielleicht erstellt er eine Software für eine 100K Videowand :stupid:

[Union]

Zitat:

Zitat von Stevie (Beitrag 1314764)

Bei ner Form mit 1200 Komponenten sollte sich eigentlich die IDE schließen und deinstallieren :duck:

Nein, das wäre unvollständig. Die HD sollte gleich noch anschließend formatiert werden :twisted:

[Harry Stahl]

Wie kann ich mir die Anzahl der Komponenten anzeigen lassen?

[Anm.: Hier geht es nicht um Programmier-Strategien (Darlo wird schon seine Gründe haben, warum er es so macht). Hier geht es rein darum, dass ein Wechseln zwischen Formular- und Source-View in XE7 auch bei ganz vielen Komponenten blitzschnell geht und in XE8 extrem langsam und in DX10 sehr langsam. Hier wird ja wohl keiner verlangen, nun deswegen seine Formulare umbauen zu müssen, damit man wieder schnell arbeiten kann. Der Ball liegt eindeutig bei EMBA].

[Union]

Zur Laufzeit mit ComponentCount.

[Harry Stahl]

Zitat:

Zitat von Union (Beitrag 1314771)

Zur Laufzeit mit ComponentCount.

OK, das ist mir natürlich auch bekannt. Ich dachte, hier gibt es vielleicht ein Auswertungs-Tool, welches solche und ähnlich nützliche Informationen ausgibt.

[mkinzler]

In der Strukturansicht Strg-A

[Union]

Der Pascal-Analyzer macht etwas in der Art. Die Anzahl musst Du dann aber selber zählen (angezeigt wird die Summe aller Controls der Anwendung):

Code:

List of all controls (1395, was 1395):
----------------------------------------------------------------------------

  dlgBerechnung : TdlgBerechnung
    pgsBerechnung : TRzProgressStatus
    lblAktivitaet : TLabel
    btnAbbrechen : TRzButton

[Harry Stahl]

OK. Meine Form hat demnach 1086 Komponenten.

Damit Ihr mal was lernt (und nicht nur feixt :wink:): In FireMonkey kommt man ganz schnell auf mehr Komponenten, als unter der VCL. Zum Beispiel jedes StringGrid mit 20 Spalten wird dann insgesamt als 21 Komponenten gezählt, in der VCL nur als eine. Bis zu XE8 musste man die FMX-Buttons noch mit einzelnen Images bestücken. Während eine VCL-TImageList mit 200 Bildchen drin nur als 1 Komponente zählt, habt Ihr in FMX dann halt 200 Image-Komponenten. Das könnte ich jetzt fortführen (TListBoxItems, TTreeviewItems, usw), wäre glaub ich aber zu langweilig...

Interessant: Wenn man in einer FMX-Form, die viele Komponenten hat, auf die oben beschriebene Weise diese auswählt, reagiert der Rechner erst mal einige Sekunden gar nicht, wenn man die Auswahl wieder aufheben möchte ... den Effekt kann man schon mit der Controls-Demo testen.

[Darlo]

8-) Wenn man Programme hat die knapp 2.500 verschiedene Daten verarbeiten kann, die gepflegt und eingegeben werden müssen kommt man auf so einige Edits und Beschriftungslabels.

In der benannten Form eben 500 Edits, 500 Labels, paar Comboboxen und ne Handvoll Layouts und nen Tabcontrol zum Organisieren.
Über andere Ansätze bin ich froh und nehme diese gerne an!

Aber zurück zum Thema. Ich hatte immer das Gefühl, dass viele gefüllte Tabsheets das ganze langsam machen.

Btw: Wie Harry bereits angefangen hat, auch jedes Item einer Combobox ist bei FMX in der Ansicht eine Komponente.

[Harry Stahl]

So, ich wollte es jetzt aber wissen (von wegen Rechner) und habe DX10 auf meinem Surface Pro 3 (i5-Prozessor, 8 GB RAM) installiert und dort mal meine Problem-Form geöffnet. Braucht dort "nur" ca. 3 Sekunden. Aber auch das ist noch viel zu lang.

Fürs testen habe ich mal eine XE7-Form gebaut (auf Basis des Controls-Demos, wo ich überwiegend nur Sachen dupliziert habe), um so auf 1070 Komponenten zu kommen.

In XE7 geht der Wechsel vom Source zum Design in 1 Sekunde, in DX10 in 9 Sekunden (auf meinem Hauptentwicklungs-PC; auf dem Surface Pro 3: in 6 Sekunden).

Diese Form liegt hier dem posting bei.

Ich habs jetzt auch mal gemeldet:

https://quality.embarcadero.com/browse/RSP-11930

Unterstützende Anmerkungen wären dort willkommen, um der Sache ein wenig Nachdruck zu verleihen.

[mensch72]

ich kann mich gerade nicht mehr komplett erinnern, aber ich hatte "irgendwo" gelesen, das die Erkennung der verschiedenen DirectX Standards schwieriger geworden ist.

Vermutung: bis XE7 war etwas neues noch nicht drin und/oder Hardware basiertes/unterstütztes GUI-Rendering wurde erkannt.
Eventuell hatte XE8 da ein Problem und fiel ganz auf Softwarerendering zurück. Wenn XE10 jetzt "etwas" schneller geht, scheint da zumindest der Kompatibilitätsmode aktiv zu sein, wo der DirectX selbst dann doch noch etwas Rendering hardware basiert macht.

... Ich muss mal suchen, waren da auch Patches dabei, wie man ForceHardware / ForceSoftware und die Fallbacks dazu anpassen muss, damit es nicht wenn mit der vollen Hardwareunterstützung nach neuestem Standard klappt ganz auf Softwarerendering zu rück geht, weil da in dem Code um den es dort ging "etwas Logik" gefehlt hat


=> Bei wem das so ist, solle man mal XE10 FMX mit verschiedenen aktuellen und älteren Grafikkarten(nicht nur OnBoardGrafik) & Grafiktreibern testen(da kann man teilweise pro Software/Spiel einstellen in welchen Mode der Grafiktreiber arbeiten soll)

[Harry Stahl]

Habe hier eine Rückmeldung von QC erhalten. Problem ist als Bug anerkannt und mit der Priority "Major" versehen:

https://quality.embarcadero.com/browse/RSP-11930

Hoffe also auf den nächsten Bugfix!:thumb: