DelphiX Cpu Entlastung ?

[ebber]

Hallo

ich dachte DelphiX ist um damit auf DirectX zuzugreifen, welches dazu dient den Cpu bei grafischen Berechnungen zu entlasten und das auf die Grafikarte zu übertragen ?

Wenn ich jetzt z.B.
von http://www.delphipraxis.net/internal...ct.php?t=43136
das unten Angehängte, was ja nur ein Bild bewegt starte, habe ich schon 100% Cpu Auslastung ?

Verstehe ich da nun irgendwas falsch ?

[Der_Unwissende]

Zitat von ebber:

Hallo

ich dachte DelphiX ist um damit auf DirectX zuzugreifen, welches dazu dient den Cpu bei grafischen Berechnungen zu entlasten und das auf die Grafikarte zu übertragen ?

Verstehe ich da nun irgendwas falsch ?

Hi,
ja da verstehst Du etwas falsch. DelphiX ist einfach nur eine Kapselung der DirectX-Funktionalität (bzw. Teile davon) in Delphi. Dies ermöglicht Dir nur von Delphi aus auf DirectX zuzugreifen. Soweit so gut.

DirectX wiederum ist keineswegs dafür da die CPU zu entlasten. DirectX ist eine Sammlung von Schnittstellen (DirectInput, Direct3D,...). Eine Schnittstelle hat den Vorteil, dass sie einfach festlegt, was für Funktionen verfügbar sind und was diese machen. Wie das ganze geschieht bleibt für Dich verborgen. Der Vorteil liegt dann darin, dass ganz unterschiedliche Hersteller von z.B. Grafikkarten die Funktionalität auch recht unterschiedlich implementieren können. Unterstützen sie die Direct3D Funktionalität in Version XYZ, dann kannst Du beide über die gleiche Schnittstelle ansprechen.
DirectX dient also vorallem als einheitliche Schnittstelle, so dass jeder Programmierer einfach auf diese Schnittstelle setzen kann (ohne die tatsächlich vorhandene Grafikkarte zu kennen).
Um hier den Perfomance-Ansprüchen (gerade in modernen Spielen) der Kunden gerecht zu werden, wird ein großteil der DirectX-Funktionalität natürlich direkt von der HW unterstützt. Ob dies auf dein Grafikkarte zutrifft und wie Du die Funktionen aufrufst, das weiß dann der Treiber. Dieser vermittelt quasi zwischen dem Aufruf des Programms und dem tatsächlichen Anzeigen auf dem Bildschirm. Die Funktionalität der Schnittstelle ändert sich (wenig überraschend) mit jeder Version. I.d.R. kommen hier neue Funktionen hinzu, die irgendwas besser/schöner/schneller machen sollen. Kommt eine neue Version raus oder muss an dem Chip
gespart werden (z.B. weil es eine Low-Budget-Version ist), wird nicht der volle Umfang der Schnittstelle direkt in HW implementiert. Für diese Fälle können die Funktionsaufrufe einfach per SW gerendert und an die Grafikkarte geschickt werden. Das ist dann wiede CPU lastig, erspart Dir aber auch den Kauf einer neuen Karte. Ob eine bestimmte Funktion von der Karte unterstützt wird oder nicht lässt sich einfach abfragen, Windows kann also einfach unterscheiden ob ein Aufruf direkt an den Treiber geht oder per SW gerendert wird.
Keiner der Wege wiederspricht dabei der Idee hinter DirectX (auch wenn man sich natürlich immer Perfomance wünscht).

Die andere Sache ist dann die Arbeitsweise einer Komponente. Ich hab mir den Quellcode nicht angeschaut und weiß auch nicht wie DelphiX genau arbeitet, aber häufig versetzt man Programme einfach in eine Endlosschleife, die auf etwas bestimmtes wartet. Typisches Beispiel wären hier auch gleich die meisten Windows-Fenster-Programme. Diese warten auch die ganze Zeit nur auf Nachrichten (die z.B. durch Interatkionen des Benutzers ausgelöst werden). Kommt eine Nachricht an, wird eine Ereignisbehandlung aufgerufen und das Warten beginnt sofort von vorne.
Bei DelphiX kommt eventuell einfach ein Ählicher Mechanismus zum Einsatz. Dafür werden meistens Threads mit niedriger Priorität verwendet. Solange nichts anderes zu tun ist, bekommt ein solcher Thread natürlich die volle CPU Zeit (die Anzeige steht bei 100%). Sobald nun aber eine andere Anwendung/ ein anderer Thread gestartet wird, hat dieser normale und damit höhere Priorität (außer auch hier wird die Priorität geändert). Ein solcher Thread würde also bevorzugt behandelt werden und nicht unter den 100% Last leiden.
Anders gesagt, die Anzeige ist hier nicht Objektiv. Die CPU ist zwar ausgelastet, aber die hier verbrauchten Ressourcen stehen auch sofort jedem anderen zur Verfügung. Würdest Du die komplette Grafik SW rendern, wirst Du den Unterschied schnell merken (da steht dann das Restprogramm solange Grafikoperationen laufen oder umgekehrt).

Gruß Der Unwissende

[ebber]

Danke für die Erleuchtung.

ich möchte sehr schnell hintereinander einige Bilder anzeigen. Das verbaucht aber meine ganze CPU Leistung.
Ist dies mit Delphi X möglich, sodass das Bild dann von/über/? die Grafikkarte angezeigt wird (und somit meinen CPU entlastet) ?

MfG

[igel457]

Die CPU sieht nur belastet aus, ist sie aber nicht wirklich. Das kommt daher, dass der Timer von DelphiX die Application.OnIdle funktion verwendet.
Erste Möglichkeit, einen "High Resolution Timer" zu verwenden. Suche mal in Google.
Zweite Möglichkeit wäre in die Timer Routine "Sleep(1)" zu schreiben. Das sieht zwar nicht schick aus, hilft aber.

[ebber]

Ich habe das Sleep 1 eingebaut aber sobald ich das Programm starte ist schon 100 % Cpu und wenn Winamp nebenher Musik abspielt fängts an zu stocken, was dann irgenwie nicht nur belastet aussieht ?

[Phobeus]

Zum einen will ich meine allgemeine Haltung zu DelphiX kund tun: Die Schnittstelle ist ein wandelndes Deadend. Du lernst einen fiktiven Aufsatz für eine veraltete Schnittstelle mit der Du nicht einmal theoretisch aktuelle Titel reproduzieren könntest. Ich empfehle jeden der sich langfristig mit dem Thema beschäftigt sich direkt in eine Grafik-Schnittstelle einzuarbeiten. Selbst ein Wechsel von Direct3D <=> OpenGL wird einfacher fallen als von DelphiX <=> DirectX.

Die Standardverarbeitung bei aktuellen Spielen ist eine Render-Loop in der das Programm nach dem Start geht und dort entsprechende Grafiken beginnt zu zeichnen. Normalerweise wird die Anwendung versuchen die gesamte zur Verfügung stehende Leistung des Systems zu verwenden, um möglichst viele Bilder die Sekunde über die Pipes zum Anwender zu hauen. Das ist grundsätzlich auch keinerlei Problem, da auf den meisten Systemen der Nutzer nur maximal 1 Spiel zu Zeit spielt. Erst im Rahmen von Notebooks kommt immer häufiger die Forderung, dass man nicht nur pur auf Leistung getrimmte Anwendungen haben möchte, sondern nur eine bestimmte Anzahl von Bildern berechnen möchte, um die übrig bleibende CPU-Zeit nicht anderweitig zu verwenden. Sleeps sind eine Möglichkeit, eine bessere wäre es den Zeitabstand zum letzten Frame zu prüfen und dann zu entscheiden, ob eine Aktualisierung des Bildes wirklich bereits wieder von nöten ist.

Grundsätzlich ist eine 100%-Auslastung bei einem Spiel nichts tragisches und Du solltest lieber die FPS messen, um einen ungefähren Eindruck über die tatsächliche Leistung zu erhalten. Dabei solltest Du Dir bewußt sein, dass DelphiX die alte DirectDraw-Schnittstelle verwendet und die überhaupt nicht von den Vorteilen einer modernen GPU profitierst. Entsprechend solltest Du Dich in deiner Anwendung vor allem mit Alpha-Blending sehr zurückhalten.

[ebber]

Danke

Gibt es vielleicht ein gutes Tutorial oder sowas wie ich DirectX ohne DelphiX benutzen kann ?

Ich will eingentlich weniger ein Spiel machen, ich habe nur ein Problem: zum Beispiel :
Ich habe eine Lampe die aus 2 Bildern besteht, einmal angeschaltet und einmal ausgeschaltet. Diese Beiden Bilder müssen dann manchmal sehr schnell wechseln, das schafft mein CPU nicht. Er kommt so schnell nicht hinterher aber es muss eingetlich schon so schnell gehen. Ich suche jetzt eine Möglichkeit die Bilder schnell genug darzustellen.

MfG

[Phobeus]

Ich denke bei Google ein Delphi + "DirectX" oder "OpenGL" wird schnell einige interessante Treffer liefern. Aber für dein Problem halte ich beide Schnittstellen ohnehin nicht empfehlenswert. Was hindert Dich daran das ganze einfach über den normalen GDI abzuwickeln? Das Zeichnen von zwei Bildern sollte eigentlich darüber recht schmerzfrei von statt gehen, sofern diese nicht gerade ein Wallpaper haben. Insbesondere bei der Verwendung von DirectDraw (also via DelphiX z.B.) sollten Dir keine nennenswerten Vorteile erwachsen, wenn es um reines blitten von Bildern geht.

[ebber]

Danke

Wie genau geht das über den normalen GDI ?
Könntest du das ein bisschen näher erleutern bitte ?


MfG

[Der_Unwissende]

Zitat von ebber:

Wie genau geht das über den normalen GDI ?

Bei GDI handelt es sich um die Windows-Schnittstelle, die für das Zeichnen zuständig ist. Dabei wird auf eine spezielle Fläche gezeichnet, die Dir vielleicht als Canvas bekannt ist. GDI ist dabei wiederum nur eine Schnittstelle, die von ganz unterschiedlichen Graphic Devices (GDI = Graphic Device Interface) implementiert werden kann. Typische Vertreter sind dabei Bitmaps ebenso wie Drucker. Beide stellen Dir eine Zeichenfläche zur Verfügung und Du kannst mit den gleichen Funktionen auf beide zeichnen (soweit das Device das Unterstützt).
In Delphi sind viele GDI Funktionen in der VCL gekapselt. Verwendest Du ein TBitmap-Objekt, so kannst Du hier über die Eigenschaft Canvas und dessen Methoden einfach auf einen fertigen Zeichencanvas zugreifen, ohne dass Du hier direkt das Win-API bemühen musst. An sich würde die Arbeit mit GDI dem Arbeiten mit TBitmap und TImage entsprechen. Wichtig ist dabei, dass Du Änderungen an einer Bitmap immer im Speicher durchführen solltest, niemals direkt die angezeigte Bitmap verändern!

Das hat einen einfachen Grund, jede Veränderung an einer angezeigten Bitmap führt zu einer sofortigen aktualisierung der Selben. Zeichnest Du 10 Linien, so wir die Bitmap auch 10 mal neu gezeichnet. Das zeichnen ist aber alles andere als flink. Hier finden jede Menge Dinge statt, es muss gewartet und synchronisiert werden, Bereiche geprüft (man darf ja nichts übermalen was eigentlich vor dem eigenen Zeichenbereich liegt), usw. Natürlich ist das neunmal völlig überflüssig, da sich hier ja gleich wieder etwas ändert.
Veränderst Du die Bitmap im Speicher, so werden nur die Daten verändert (die ja nirgends angezeigt werden). Das zeichnen einer ganzen Bitmap sollte dann auch recht flink gehen. Dazu kannst Du entweder die Bitmap dem Image zuweisen oder mit der Funktion BitBlt einfach den Inhalt des Canvas vom einem Bitmap auf den Canvas des anderen kopieren (auch eine sehr schnelle Funktion!)