GDI Handles einer Anwendung

[Whookie]

Ich hab hier mal eine App mit knapp 100 Forms - die eine Art Bildbearbeitung erlaubt - und die Spitzenwerte im GDIView sind 460/650 (bei intensivem Arbeiten) also weit ab von jeglichen Problemen.
Auch das Öffnen und Bearbeiten von ettlichen (10) Grafikdateien mit gemeinsam gut 300 Layern verbraucht gerade mal 350/420 Handles (alle Ebenen sichtbar + Kopien in neuen Bildern).

Grundsätzlich stellt sich also die Frage ob ein so hoher Wert nicht einfach ein Designproblem ist?

Was Delphiprogramme anbelangt mache ich mir da jedenfalls keine Sorgen.

[mm1256]

Zitat von Whookie:

Grundsätzlich stellt sich also die Frage ob ein so hoher Wert nicht einfach ein Designproblem ist?

So sehe ich das auch und wette mal einen alten Hut gegen einen neuen PC, dass sehr extensiv (wenn überhaupt) von der Möglichkeit Gebrauch gemacht wird, Formulare dynamisch zur Laufzeit zu erzeugen, und wenn sie nicht mehr gebraucht werden wieder freizugeben. Testweise habe ich mit dem og. Tool mal meine größte App geprüft, eine MDI-Anwendung mit insgesamt über 150 Fenstern/Formularen. Wenn ich alle 12 MDI's aufmache und dazu noch einen modalen Dialog mit Bildanzeige (mehr geht nicht) dann komme ich auf ~700 Handles (All GDI).

[Alex_ITA01]

Danke für eure Antworten.
Jetzt kommen wir doch der Sache näher.

Doch, ich habe die meisten Fenster dynamisch gestaltet.

Ich komme ja in der Spalte "GDI Total" auf nur knapp 1000. Aber bei "Alle GDIs" stehen mal eben 5000.
Die Frage ist also immernoch, wo kommt diese Differenz her, da ich ja anscheind keinen Einfluss darauf nehmen kann. Also was für Handles könnten das sein, die sich als GDI Handle ausgeben aber nicht in der GDI Handle Table stehen. Ich bin ja gerne bereit etwas an meinem Design der Anwendung zu ändern aber dafür müsste ich ja erstmal wissen, wo ich anpacken kann.

Viele Grüße

[mm1256]

Hallo,

wenn ich mir auf meinem Arbeits-PC das Verhältnis von "GDI Total" zu "All GDI" ansehe, dann fällt mir positiv der TeamViewer mit 442 zu 483 auf, und negativ der Total-Commander mit 207 zu 429. Da schlagen vermutlich die vielen Bitmaps zu. Wenn ich z.B. die Laufwerkbuttons weg nehme, sind es nur mehr 165 zu 390.

So ähnlich könnte es sich vielleicht bei dir auch verhalten. Abhilfe....vielleicht ImageList verwenden, Fenster vererben...usw. Läuft halt ohne Detailkenntnisse leider nur auf Glaskugel hinaus. Du müsstest also schon etwas mehr Infos/Details benennen.

[Alex_ITA01]

aber in dem Verhältnis 207 zu 429 sind doch in den 207 die Bitmaps mit drinne.
Also egal wie hoch die Anzahl ist, ich würde ja gerne mal wissen, was die anderen Handles für welche sind, da ja Bitmaps zu dem ersten Wert gehören. Die sind für mich auffindbar und anpassbar...

Viele Grüße

[Alex_ITA01]

Noch ein Beispiel:

Leeres Formular mit einem Button hat ungefähr ~40 GDI Handles (Total GDIs) -- Verhältnis 3 / 43.
Beim Button Klick ein zweites Formular dynamisch erzeugen mit einem leeren VirtualStringTree drauf (keine Eigenschaften angepasst). Verhältnis 9 / 140

Also auf einmal 100 GDI Handles mehr (Totale GDIs, nicht die aufsummierten aus Bitmap und Co) nur wegen einem Formular und einem VirtualStringTree.

Ich würde nur zu gerne wissen, was das für Ressourcen sein sollen...

Viele Grüße

[TiGü]

Zitat von Alex_ITA01:

Ich würde nur zu gerne wissen, was das für Ressourcen sein sollen...

Was genau hält dich jetzt auf in die Quelltexte des Frameworks zu gucken?

Beispiel:
TCustomForm hat einen TControlCanvas, der wiederrum alle entsprechenden Eigenschaften belegt (Font, Pen, Brush) und die Elternklasse TWinControl hat einen TBrush als Membervariable. Allein schon das erzeugen von derartigen Objekten belegt GDI-Ressourcen.