Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Software-Projekte der Mitglieder (https://www.delphipraxis.net/26-software-projekte-der-mitglieder/)
-   -   the Power of (Tests verschiedener Render Funktionen) (https://www.delphipraxis.net/196935-power-tests-verschiedener-render-funktionen.html)

himitsu 2. Jul 2018 10:38

AW: the Power of
 
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:

Zitat von EWeiss (Beitrag 1406292)
Ja.. Aber schaue auf die Leistung der CPU

So groß ist der Unterschied nun auch nicht.

EWeiss 2. Jul 2018 10:41

AW: the Power of
 
Zitat:

Zitat von himitsu (Beitrag 1406296)
Zitat:

Zitat von EWeiss (Beitrag 1406292)
Ja.. Aber schaue auf die Leistung der CPU

So groß ist der Unterschied nun auch nicht.

Hmm.. dann habt ihr Power CPU's bei mir macht es satte 12% aus. (Vielleicht der Unterschied zwischen Win7 und Win10) ;)
Danke für die Info.

Zitat:

Naja gut, das heißt aber nicht, dass man nicht mehr berechnen kann.
In der Praxis macht es natürlich keinen Sinn mehr zu rendern, als der Bildschirm darstellen kann,
aber für einen Performance Test sollte man Rendern lassen bis die CPU/GPU qualmt und schauen was man rausholen kann (egal wie viel der Bildschirm kann).
Nun ich habe es mit GetTickCount und MMSystem versucht bekomme nicht mehr Frames angezeigt als der Monitor hergibt.
66 FPS ist das Maximum bei mir.

Der Timer selbst ist auf 5ms ausgelegt denke nicht das bei 0 mehr FPS angezeigt werden.

gruss

himitsu 2. Jul 2018 11:13

AW: the Power of
 
Zitat:

Nun ich habe es mit GetTickCount und MMSystem versucht bekomme nicht mehr Frames angezeigt als der Monitor hergibt.
66 FPS ist das Maximum bei mir.
Mit fsync oder so.

Wenn das mit der Ausgabe gekoppelt ist, wird es ausgebremst, da mehr eh nicht nöötig ist.

Und Timer ... kommt drauf an welche.
Denn einige Timer haben eine Minimal-Auflösung. (z.B. TTimer und GetTickCount haben einen internen Takt von etwa 16ms)

EWeiss 2. Jul 2018 11:24

AW: the Power of (Tests verschiedener Render Funktionen)
 
Zitat:

Denn einige Timer haben eine Minimal-Auflösung. (z.B. TTimer und GetTickCount haben einen internen Takt von etwa 16ms)
Ja deshalb komme ich auch nicht über 60 FPS weil ich einen "normalen" Timer (TTimer) verwende..
Selbst mit der Berechnung der FPS über timeGetTime (MMSystem) komme ich nicht drüber weil mit meinem Timer wie du schon sagst bei 16ms schluss ist.
Werde dann wohl direkt mit TimeSetEvent also einen Timer auf Threadbasis arbeiten müssen wenn ich höhere Frames anzeigen will.

Werde das mit meinem erweiterten sample abändern.

gruss

EWeiss 2. Jul 2018 19:41

AW: the Power of (Tests verschiedener Render Funktionen)
 
Hat leider etwas länger gedauert.
Ich musste erst eine neue Funktion für meine Library schreiben die es mir ermöglich direkt im Speicher die Bitmap Objekte zu resizen ohne Umweg über speichern und Konsorte.

Neuer Upload im ersten Beitrag.
Es werden 200 Animierte Sprites zur gleichen zeit gerendert.

Wenn man die Qualität testen will muss in den jeweiligen Funktionen der Radio Button das IsWindowVisible kommentiert werden
damit man zugriff auf die einzelnen Funktionen bekommt.

gruss

EWeiss 3. Jul 2018 05:21

AW: the Power of (Tests verschiedener Render Funktionen)
 
Ich verwende jetzt den MMTimer..
Wenn ich jetzt den Timer auf 1ms stelle dann habe ich folgende Resultate.

TransBlt = 410 FPS aber 25% CPU
AlphaBlend = 358 FPS auch 25% CPU
Composited = 86 FPS 25% CPU

Nur! Was für einen sinn macht das die Anwendung mit vollem Speed laufen zu lassen wenn dadurch die CPU anschließend mit 25% ausgelastet wird?
Gut ich sehe die Frames die real gerendert werden wenn man mal davon absieht das beim 60HZ Monitor eh nur max 66 FPS dargestellt werden können.

Ist schon fragwürdig das ganze.

gruss

KodeZwerg 3. Jul 2018 07:14

AW: the Power of (Tests verschiedener Render Funktionen)
 
Zitat:

Zitat von EWeiss (Beitrag 1406390)
Nur! Was für einen sinn macht das die Anwendung mit vollem Speed laufen zu lassen wenn dadurch die CPU anschließend mit 25% ausgelastet wird?

Sinn und Zweck bei Performance Tests ist nunmal die Quantität. Von daher hast Du alles Richtig gemacht, mit einem VSync Knopf sollte sich das Ergebnis dann grob auf die Hz des Monitors einstellen. Falls noch nicht vorhanden bitte reinbasteln. So hat man eine Cpu- & Gpu- schonende und total unlocked Variante für deine Api zum testen.

EWeiss 3. Jul 2018 07:24

AW: the Power of (Tests verschiedener Render Funktionen)
 
Zitat:

Zitat von KodeZwerg (Beitrag 1406395)
Zitat:

Zitat von EWeiss (Beitrag 1406390)
Nur! Was für einen sinn macht das die Anwendung mit vollem Speed laufen zu lassen wenn dadurch die CPU anschließend mit 25% ausgelastet wird?

Sinn und Zweck bei Performance Tests ist nunmal die Quantität. Von daher hast Du alles Richtig gemacht, mit einem VSync Knopf sollte sich das Ergebnis dann grob auf die Hz des Monitors einstellen. Falls noch nicht vorhanden bitte reinbasteln.

Dir ist aber schon klar das GDI\GDI+ keinen Zugriff auf das VSync Signal hat oder?
Da ist nix mit reinbasteln in welcher Form auch immer.

OpenGL\DirectX kein Problem.. aber das verwende ich nun mal nicht ;)

Man kann die Frames noch etwas genauer analysieren\setzen über DWM_TIMING_INFO das war's aber auch schon.
Zitat:

So hat man eine Cpu- & Gpu- schonende und total unlocked Variante für deine Api zum testen.
Ich weis nicht wo du deine Infos herholst.
Auch hier GDI\GDI+ werden niemals über die GPU Rendern das ist etwas für OpenGL\DirectX.

gruss

KodeZwerg 3. Jul 2018 07:38

AW: the Power of (Tests verschiedener Render Funktionen)
 
Ich dachte das Du das vorher mit dem Timer so abgeglichen hattest das bei um die 60 FPS ein lock stattfindet und nun ists unlocked auf 1ms ?
Hab mal eine Frage was bei Dir passiert wenn Du folgendes machst: Programm starten, auf [Animate] klicken, auf [Start] klicken. Staunen.
Das erinnert mich an den Duracell-Hasen, nur das der Pinguin hier auf Speed ist ^_^

EWeiss 3. Jul 2018 07:45

AW: the Power of (Tests verschiedener Render Funktionen)
 
Zitat:

Hab mal eine Frage was bei Dir passiert wenn Du folgendes machst: Programm starten, auf [Animate] klicken, auf [Start] klicken. Staunen.
Gar nichts passiert da weil das Timing bzw. der Interval mittlerweile angepasst wurde. :lol:

Zitat:

Ich dachte das Du das vorher mit dem Timer so abgeglichen hattest das bei um die 60 FPS ein lock stattfindet und nun ists unlocked auf 1ms ?
Da steht hier nirgends was von.

Was soll das bringen ich will die vollen möglichen Frames anzeigen und nicht irgendetwas blocken.
Und wie gesagt vergiss es mit VSync und anderer diverser Hilfsmittel ist alles zu ungenau und in dem fall bringt es nichts.

EDIT:
Der unterschied wie @himitsu schon sagte ist das der Taktgeber beim TTimer\SetTimer nun mal auf 16ms festgelegt ist mehr bekommst du nicht auch dann nicht
wenn du diesen auf 0 setzt das hat aber nichts mit eigenständigen blocken oder (lock) zu tun.. es ist vorgegeben.
Der MMTimer unterliegt dieser Beschränkung nicht deshalb kann man hier die Maximale FPS herauskitzeln wenn man den Timer auf 1 setzt.
Aber wie schon gesagt das hat nix mit setzen einer Sperrung\Beschränkung zu tun.

Mit setzen des VSync Signal lege ich nur fest das die FPS anzeige so ausgegeben wird wie der Monitor diese wiedergeben kann.
Das geht aber mit GDI und GDI+ nicht das sagte ich aber schon.

Zitat:

Das erinnert mich an den Duracell-Hasen, nur das der Pinguin hier auf Speed ist ^_^
Nun ein einzelnes Animiertes Sprite mit dieser Auflösung hat dann aber auch eine FPS jenseits der grenze von 800.

gruss


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:44 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz