the Power of (Tests verschiedener Render Funktionen)

[EWeiss]

Speed vergleich sowie Qualität unterschiedlicher Render Funktionen TransBlt, AlphaBlend sowie Kombination von Vordergrund und Hintergrund.
Source include.

Anhang gelöscht. (Test erfolgreich)

gruss

[Daniel]

Um welche Render-Funktionen handelt es sich? Wie unterscheiden sich diese technisch? Ein bisschen weiter musst Du Deinen Beitrag schon unterfüttern und um einen aussagekräftigen Titel möchte ich Dich ebenfalls bitten.

[Neutral General]

Also die FPS sind bei mir bei allen 3 Beispielen ziemlich identisch.
Bei der Qualität kann ich auch keine Unterschiede erkennen, aber das muss nichts heißen :mrgreen: (Ich hab für sowas nicht unbedingt ein Auge)

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1406282)

Um welche Render-Funktionen handelt es sich? Wie unterscheiden sich diese technisch? Ein bisschen weiter musst Du Deinen Beitrag schon unterfüttern und um einen aussagekräftigen Titel möchte ich Dich ebenfalls bitten.

Hoffe es ist dir so recht. ;)

Zitat:

Also die FPS sind bei mir bei allen 3 Beispielen ziemlich identisch.

es hat damit zu tun das bei 60Hz nun mal nicht mehr Frames angezeigt werden können als Maximal 60 > 66 Frames.
Bei einem 75Hz Monitor sollte das schon anders sein.

Zitat:

Bei der Qualität kann ich auch keine Unterschiede erkennen

Bei TransBlt fehlt das Alphablend sollte man eigentlich gut erkennen.
Random Gradient anklicken wenn man es nicht gut erkennen kann dafür habe ich es addiert. ;)
Der unterschied bei Alphablend und Composited ist das beim ersten der Hintergrund unbeachtet bleibt.
Das zweite kopiert den Hintergrund in das Sprite und rendert beides gleichzeitig was sich dementsprechend auf die CPU auswirkt.

Ich werde es noch etwas ausweiten mit einem Sprite test der 200 Animierte einzelne Sprites (geklonte) auf einmal rendert und jedes einzelne für sich
aus wählbar und verschiebbar macht.

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1406285)

Bei TransBlt fehlt das Alphablend sollte man eigentlich gut erkennen.

Nein.
Sorry, wenn da alles so schnell rumfliegt, wie soll man da kaum sichtbare Farbunterschiede bemerken?

Aber mit einem helleren Hintergrund fällt es dann auf.



Genau deswegen sollte man schon schreiben, worum es geht und wofrauf man achten muss.


@Titel: Und ich dachte anfangs es geht um Mathematik.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1406289)

Zitat:

Zitat von EWeiss (Beitrag 1406285)

Bei TransBlt fehlt das Alphablend sollte man eigentlich gut erkennen.

Nein.
Sorry, wenn da alles so schnell rumfliegt, wie soll man da kaum sichtbare Farbunterschiede bemerken?

Aber mit einem helleren Hintergrund fällt es dann auf.

Ja habe meinen Beitrag editiert.. Danke.

Zitat:

Random Gradient anklicken wenn man es nicht gut erkennen kann dafür habe ich es addiert.

Zitat:

Und ich dachte anfangs es geht um Mathematik.

Es ist ja auch etwas dabei wenn man in den Source schaut ;)

gruss

[Neutral General]

Zitat:

Zitat von EWeiss (Beitrag 1406285)

Zitat:

Also die FPS sind bei mir bei allen 3 Beispielen ziemlich identisch.

es hat damit zu tun das bei 60Hz nun mal nicht mehr Frames angezeigt werden können als Maximal 60 > 66 Frames.
Bei einem 75Hz Monitor sollte das schon anders sein.

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).

Zitat:

Zitat von EWeiss (Beitrag 1406285)

Zitat:

Bei der Qualität kann ich auch keine Unterschiede erkennen

Bei TransBlt fehlt das Alphablend sollte man eigentlich gut erkennen.
Der unterschied bei Alphablend und Composited ist das beim ersten der Hintergrund unbeachtet bleibt.
Das zweite kopiert den Hintergrund in das Sprite und rendert beides gleichzeitig was sich dementsprechend auf die CPU auswirkt.

Bei mir sieht beides gleich aus :gruebel: (Siehe Anhang)

EDIT: Ja mit nem anderen Gradient sieht mans - hat sich erledigt.

[EWeiss]

Zitat:

Bei der Qualität kann ich auch keine Unterschiede erkennen
Bei mir sieht beides gleich aus :gruebel: (Siehe Anhang)

Zitat:

EDIT: Ja mit nem anderen Gradient sieht mans - hat sich erledigt.

Ja.. Aber schaue auf die Leistung der CPU :)
Was passiert wenn man den Hintergrund in das Sprite kopiert und anschließend beides gleichzeitig rendert.

gruss

[Neutral General]

Transparent + Alphablend verbrauchen bei mir zwischen 0,1% und 0,3% CPU.
Composited benötigt 2,7% - 3,7%

[EWeiss]

Zitat:

Zitat von Neutral General (Beitrag 1406293)

Transparent + Alphablend verbrauchen bei mir zwischen 0,1% und 0,3% CPU.
Composited benötigt 2,7% - 3,7%

Dann hast du aber richtig power kann das sein?
Ich habe hier bei den ersten 0% und das letzte 10 > 12% (Core2 Quad Q9650 3GHZ)

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1406292)

Ja.. Aber schaue auf die Leistung der CPU

So groß ist der Unterschied nun auch nicht.

[EWeiss]

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]

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]

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]

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]

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]

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]

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]

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]

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