CapFrameX - Capture und Analyse Tool

@Windt4 Der Erfahrung nach stecken sehr oft Virenscanner dahinter, wenn OCAT nichts aufzeichnet. Auf Platz eins ist jedoch, dass der Hook nicht funktioniert, was man mit der Option "Capture performance for all processes" oder/und mit dem Deaktivieren des Overlays in den Griff bekommen kann. In manchen Fällen ist tatsächlich sogar die Engine des Spiels nicht kompatibel oder anderes herum. Wie man es halt sehen will. ^^

Aber schön, dass es jetzt klappt!

Allgemeine Info: Ich habe mich mit Jefferson Montgomery (Intel) in Verbindung gesetzt. Er ist der Entwickler von PresentMon, worauf OCAT letztlich aufsetzt. Er hat mir einen guten Trick verraten, wie ich den Input Lag aus den Daten ziemlich genau schätzen kann. Diese Info bleibt natürlich nicht ungenutzt und wird vermutlich in die kommende Version mit einfließen.

@Haldi So ein farbliches Mapping zwischen Graph und Balkengruppe habe ich mir auch schon gewünscht. Ich muss mal schauen, ob ich da was machen kann. Im Moment bin ich nicht sonderlich optimistisch, weil es ein Format-Delegate für alle Einträge gibt. Die Einträge werden also alle gleichermaßen formatiert. Es halt eine Fremdbibliothek, die ich verwende. Ich kann deswegen konfigurationstechnisch nicht unbegrenzt in die Tiefe gehen. Aber vielleicht fällt mir noch ein Trick ein....

Edit: Wie hast du es denn hinbekommen, dass die Liste auf der rechten Seite in der Comparison Page so klein ist und dadurch eine Lücke nach unten hin entsteht? ^^ Kann ich hier nicht reproduzieren.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Haldi, Windt4 und ChrisMK72
ZeroStrat schrieb:
Edit: Wie hast du es denn hinbekommen, dass die Liste auf der rechten Seite in der Comparison Page so klein ist und dadurch eine Lücke nach unten hin entsteht? ^^ Kann ich hier nicht reproduzieren.
Das ist eine verdammt gute Frage xD
Dacht schon iwas sei komisch als ich nach nem Resize da die Weisse fläche hatte.
Aber als es nach weiterem Resizen und neuem öffnen immer noch da war hab ich's aufgegeben.
 
ZeroStrat schrieb:
Allgemeine Info: Ich habe mich mit Jefferson Montgomery (Intel) in Verbindung gesetzt. Er ist der Entwickler von PresentMon, worauf OCAT letztlich aufsetzt. Er hat mir einen guten Trick verraten, wie ich den Input Lag aus den Daten ziemlich genau schätzen kann. Diese Info bleibt natürlich nicht ungenutzt und wird vermutlich in die kommende Version mit einfließen.
Faszinierend, was man aus diesen ganzen Daten, die einem OCAT ausspuckt doch auslesen kann, wenn man weiß, wofür das alles steht^^
Ich hatte ja nicht mal gedacht, dass man überhaupt aufzeichnen kann, wann ein Bild vom Monitor ausgegeben wird und damit die Synchronisation testen kann.

Gibt es eigentlich bereits eine aktuellere Beta oder ist noch eine vor Release geplant?
 
@Taxxor: Die Renderpipeline hat halt einige Stufen. Dazu kommen noch die Monitoraktualisierungszeiten. Aber es ist tatsächlich faszinierend, was PresentMon alles für Infos extrahieren kann.

Wegen der Beta, den aktuellen Stand kann ich keinem zumuten. ^^
 
Zuletzt bearbeitet von einem Moderator:
@ZeroStrat Noch eine Anregung zum Stuttering Wert:

Der Wert sollte die Schwere der Ruckler mehr berücksichtigen, als er es momentan tut.
Denn es ist ja ein Unterschied, ob bei Faktor 2,5 und einem average FPS Wert von 60(16,66ms) jetzt über einen Benchmark von 20s Länge 10 Frames drin sind, die 42ms haben, oder 10 Frames, die 300ms haben.

Der Stuttering Wert als prozentualer Vergleich der Stutter Frames über die Gesamtframes würde in beiden Fällen nahezu gleich sein, obwohl man im zweiten Fall sehr viel stärker durch Ruckler beeinträchtigt wurde.


Eine mMn gute Möglichkeit wäre, im Kuchendiagramm nicht die Anzahl der Stutter Frames und restlichen Frames zur Gesamtanzahl der Frames zu vergleichen, sondern die Summe der Zeit aller Stutter Frames und die Summe der Zeit aller restlichen Frames zur Gesamtzeit.



Der Einfachheit halber sagen wir mal, alle übrigen Frames hätten einen Schnitt von 16,66ms.

1. Run
10 Frames mit 42ms, übrige Zeit: 19580ms
der Rest 16,66ms : 1175 Frames
Gesamtframes: 1185

2. Run
10 Frames mit 300ms, übrige Zeit: 17000ms
der Rest 16,66ms : 1020 Frames
Gesamtframes : 1030


Aktuelle Variante: Stuttering für "Summe der Stutter Frames über Gesamtframes"
  1. Run: 10/1185 = 0,84%
  2. Run: 10/1030 = 0,97%
Mein Vorschlag: Stuttering für "Summe der Stutter Frametimes über Gesamtzeit"
  1. Run: 420ms/20000ms = 2,1%
  2. Run: 3000ms/20000ms = 15%
Die genaue Anzahl der Stutter Frames, womit das Diagramm momentan arbeitet, kann man ja weiterhin als Zusatzinfo noch unter das Diagramm schreiben.
Jedoch halte ich für die Darstellung im Diagramm selbst meine Variante für besser, da hier eher angegeben wird, über welchen Zeitraum man Ruckler hatte.

Und da ist es schon ein großer Unterschied, ob man in 20 Sekunden insgesamt 0,42s oder 3s lang Ruckler wahrnehmen konnte(im zweiten Fall sind es ja regelrechte Hänger statt Mikrorucklern), was die 0,84 und 0,97 Werte aber überhaupt nicht wiederspiegeln.

Noch krasser könnte man auch ein Szenario nehmen, wo es im zweiten Run nicht 10 Frames mit 300ms sondern nur 5 Frames, dafür aber mit 600ms sind. In dem Fall wäre der aktuelle Stuttering Wert mit 0,44 dann fast doppelt so gut wie der des ersten Runs, obwohl das Spiel in 20 Sekunden 5 mal für über eine halbe Sekunde still stand.
Dafür ist dann auch die zusätzliche Angabe der Stutter Frames unter dem Diagramm hilfreich, damit man direkt sehen kann, ob diese 15% Ruckeln aus 5 großen Hängern oder 50 kleinen Rucklern bestehen.

So oder so ähnlich stelle ich mir das vor
pie.jpg
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZeroStrat und Windt4
@Taxxor Wenn eine Frametime rausschießt und Stuttering verursacht, ist es dann nicht egal, wie lange das ist? Hänger ist halt Hänger. Falls das dennoch interessant ist, baue ich es ein. Es ist einfach zu bewerkstelligen, kein Thema. Dann müssen wir habe über Frametime-Summen sprechen, oder?

  • Frametime sum without stuttering
  • Frametime sum with stuttering
 
@ZeroStrat wie gesagt, bei average 60fps wäre jede frametime mit über 42ms als stutter angegeben.
Und da macht es einen Unterschied, wenn diese frametime das nächste Bild statt den üblichen 16ms plötzlich 50ms oder 500ms verzögert. Ein +34ms Hänger ist nicht gleich einem +484ms Hänger.

Im ersten Fall merkst du vielleicht einen kleinen Ruckler, je nachdem was die Szene gerade dabei darstellt merkst du es vielleicht auch gar nicht.
Perspektivenwechsel aus einem Panzer heraus oder der Wechsel nach dem Tod auf das Luftbild der Map in Battlefield V wurde im anderen Thread z b. angesprochen:
BF1_Spikes.png


Ist laut Aussage des Nutzers nicht wahrnehmbar trotz Frametime Spike von 5-8ms auf 35-45ms(sind ja auch immer noch 22-28fps, für 1-2 Frames in denen eine Ansicht gewechselt wird nicht weiter störend).

Dein Stuttering Wert sagte in diesem Fall 0,04.
Da ich die Datei nicht habe rechne ich das einfach mal runter, mit den ca. 45000 Frames wären das insgesamt 18 Stutter Frames(bei den Average FPS von 151 ist alles über 16,56ms ein Stutter Frame)
3 sind im Bereich 44ms, zwei bei 36ms und zwei bei 33ms, die restlichen 11 sind alle um besagte 17ms.
Macht eine Frametime Summe von ca 460ms gegen ca 300.000ms Gesamtzeit(45000 Frames/151avg fps)
"Mein" Stuttering Wert läge demnach hier bei 460/300.000 = 0,15%, nicht so weit weg von deinem.


Würde das Bild aber in diesen 7 Fällen jeweils für eine halbe Sekunde still stehen, merkst du das definitiv.
Dann hättest du ca 7x460ms weniger für die restlichen Frames, bei den 151 avg FPS fallen dadurch 520 Frames weg, dein Stuttering Wert läge aber immer noch bei 18/44480 = 0,04%
"Mein" Stuttering Wert würde jetzt bei 7x500ms und 11x17ms 3.687/300.000 = 1,23% sein, schon bedeutend höher als die 0,04% oder auch meine vorherigen 0,15%, eben weil man jetzt ein paar Frames hat, in denen man auch wirklich stark ein Stottern bemerkt.

Und ja, Summe der Frametimes sind es dann, ich dachte dass da die Angabe "Frametimes" statt "Frames" ausreicht.
Oder man sagt einfach nur "Time with stuttering" und "Time without stuttering"




Edit: Bei No Man's Sky habe ich z.b. auch gerne mal Nachladeruckler, wo ein einzelner Frame dann zwischen 1000 und 2000 ms hat. Das ist sehr von einem Drop auf 50ms zu unterscheiden.
Ich fand das Beispiel im vorherigen Post schon krass, aber man kann auch mein No Mans Sky Beispiel nehmen, dann wirds noch krasser: 10 Frames mit je 1000ms.

Damit hättest du bei einem 20s Benchmark nur 10 Sekunden lang überhaupt ein bewegtes Bild, der Stuttering Wert sollte also logischerweise bei 50% liegen.
Dein Wert wäre(bei ansonsten ca 60fps)10/610 = 1,64%
Und dabei habe ich bei No Mans Sky ansonsten weit über 60fps, die Frametimes sind eher so um die 10ms, dann wird deine Berechnung noch weniger aussagekräftig.
Dann sind es nämlich nicht 600 sondern 1000 flüssige Frames in 10 Sekunden und 10 Stutter Frames in den anderen 10 Sekunden, gesamt dann 1010 Frames, und 10/1010 wären dann nur 0,99% Stuttering für eine Szene mit 50% Standbild.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZeroStrat und Windt4
@Taxxor: Nach einer kleinen Pause arbeite ich wieder intensiv an CapFrameX. Das hier ist die neue Darstellung der prozentualen Stuttering Zeit genau nach deinem Vorschlag umgesetzt.

Das ist die Formel dazu:
C#:
public double GetStutteringTimePercentage(IList<double> sequence, double stutteringFactor)
{
    var average = sequence.Average();
    var stutteringTime = sequence.Where(element => element > stutteringFactor * average).Sum();

    return Math.Round(100 * stutteringTime / sequence.Sum(), 3);
}
 

Anhänge

  • Stuttering_Pie_Chart.png
    Stuttering_Pie_Chart.png
    111,2 KB · Aufrufe: 422
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Haldi, Taxxor und cm87
@ZeroStrat Das sieht doch schon mal sehr schön aus, damit fehlt auf der Seite ja dann nur noch die Auswahl der anzuzeigenden Werte links.

Übrigens: Wenn du das Programm auf Englisch belassen willst, solltest du vielleicht die Kommata durch Punkte ersetzen, wie es im englischen üblich ist, um Verwirrung zu vermeiden.
Innerhalb eines komplett englischsprachigen Fensters habe ich die Smooth Time z.B. instinktiv als 37105s gelesen
 
  • Gefällt mir
Reaktionen: ZeroStrat
Oh verdammt ja, die Dezimaltrenner müssen natürlich Punkte sein. Danke! Ja, die Auswahl fehlt noch. Es sollen noch die "Youtube-Parameter" usw. auswählbar gemacht werden...

Ist alles in Arbeit. Und es ist noch viel Arbeit. ^^

Edit: Wie war das noch Taxxor, du kannst C# und hast Bock zu helfen?! ^^
 
  • Gefällt mir
Reaktionen: cm87
ZeroStrat schrieb:
Edit: Wie war das noch Taxxor, du kannst C# und hast Bock zu helfen?! ^^
Leider überhaupt nicht, aber ich bemühe mich stattdessen umso mehr um konstruktives Feedback^^


ZeroStrat schrieb:
Es sollen noch die "Youtube-Parameter" usw. auswählbar gemacht werden...
Die du aber hoffentlich nicht "Youtube 1%" und "Youtube 0.1%" nennen wirst^^
 
  • Gefällt mir
Reaktionen: cm87 und ZeroStrat
Das ist wirklich auch schon eine große Hilfe! 👍

Taxxor schrieb:
Die du aber hoffentlich nicht "Youtube 1%" und "Youtube 0.1%" nennen wirst^^

Doch, das ist eine gute Idee. Auf diese Weise kann ich meine kritische Haltung den Werten gegenüber demonstrieren. :p
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: cm87 und Taxxor
ZeroStrat schrieb:
Doch, das ist eine gute Idee. Auf diese Weise kann ich meine kritische Haltung den Werten gegenüber demonstrieren.
Ich würde für die Quantile auch keine Prozentangabe wählen.

Denn der 1% Wert z.B. ist ja nicht
"Das unterste Prozent der Werte"
sondern es ist ja
"Ein exakter Punkt an der Schwelle zum untersten Prozent der Werte"

Und einen exakten Punkt kann man angeben mit dem "x-ten Wert", daher auch die Bezeichnung von CB mit "99th" statt 99%, da es nur das 99. Perzentil der Werte und nicht 99 Prozent der Werte beschreibt.
Alternativ könnte man, um die Perzentil Werte zu beschreiben, auch P0.1, P1, P5, P95 und P99 nehmen, da die
"X-th" Formulierung bei 0.1 und 1 nicht so schön aussehen würde.

Der Prozentwert suggeriert mir eher die "Youtube Parameter", weil für mich die Angabe "1%" ganz simpel wie oben beschrieben "das unterste Prozent" bedeutet und (damit logischerweise mehrere Werte) und nicht "der beste Wert des schlechtesten Prozent"

Je nachdem wie ausschweifend du das bezeichnen willst würde ich die YT Parameter in einer dieser Varianten benennen:
"avg 1% low"
"1% low"
"avg 1%"
 
Zuletzt bearbeitet:
@Taxxor Neues Konzept für die Kommentare und CPU/GPU Infos. Es wird bei jedem Wechsel des Records neu eingeblendet und ist unmittelbar zugänglich. Würde ich das DataGrid mit neuen Spalten erweitern, die die gleichen Infos enthalten, würde das arg den Platzrahmen sprengen.
 

Anhänge

  • CX_Custom_Comments_UI.png
    CX_Custom_Comments_UI.png
    438,1 KB · Aufrufe: 483
@ZeroStrat
Die Infos zu CPU GPU und den Custom Comment sieht man ja auch rechts bei der System Info, wenn man die entsprechende Datei ausgewählt hat.

Die Permanente Anzeige links erleichtert zumindest das Verändern der Custom Angaben, das finde ich also gut und sollte auch so bleiben.

Jedoch hilft sie leider auch nicht dabei, aus einer Liste von 35 Messungen mit dem Namen "MetroExodus", die passende zu finden, ohne immer wieder alle durchgehen zu müssen und dabei die Custom Comment Spalte zu beobachten.

Ich finde wenigstens der Custom Comment müsste dafür eine Spalte bekommen und da sehe ich auch den Platzbedarf nicht allzu tragisch, da so ein Comment ja auch bei Bedarf gut abgekürzt werden kann und nicht viel länger als z.B. das Datum sein wird.
Auf einem 16:9 Bildschirm ist, finde ich, hier noch genug Platz für wenigstens diese Spalte:
764017

Gut, das ist jetzt auch 1440p, aber auch bei 1080p ist noch genug Platz

Und außerdem: Wer den Platz braucht, kann die Spalte doch einfach ausblenden, ich kann in der aktuellen Version zumindest das Hauptfenster soweit nach links ziehen, dass ich nur noch Game und Date sehe.
Wobei, ich glaube präzise ist es eher der Rechte Rand der Time Spalte, den ich ziehe, egal, das Ergebnis ist das gleiche.
 
Zuletzt bearbeitet:
Hast du gesehen, wie lang die Kommentare sein können? Ich weiß nicht, wie so ein Text im Allgemeinen in eine normal breite Spalte passen soll.
 
@ZeroStrat Also bei deinen jetzigen Spalten wird er doch einfach abgeschnitten, wenn ich die Spalte kleiner ziehe als das, was drin steht. Das würde doch beim Comment dann genau so funktionieren, man müsste nur eine feste Spaltenbreite festlegen, die beim Programmstart gesetzt wird und sich nicht direkt dem längsten Comment anpasst.

Und in deinem Beispiel würde ich dann schon mal mindestens "1080p" lesen können, was die Auswahl der möglichen gesuchten Datei vermutlich schon von z.B. 9 auf 3 reduziert.

Wenn ich mehr Infos will kann ich die Spalte bei Bedarf ja auch einfach so ziehen, dass ich wirklich auch verdammt lange Comments komplett sehen könnte:
764046

Nachdem ich die Datei gefunden und ausgewählt bzw. in diesem Fall in die Comparison eingefügt habe, kann ich die Spalte ja wieder kleiner ziehen.
 
Zuletzt bearbeitet:
Ich bin mir da nicht so sicher, ob die Info so hilfreich ist, wenn man das abschneidet. Gerade wenn es sehr viele Einträge sind mit gleichen Anfang bringt es ja nichts mehr. Hmmm...
 
In dem Fall kann man sich die Spalte ja kurzzeitig breiter ziehen.

Du könntest diese Spalte ja auch togglen lassen mit einem Häkchen irgendwo oberhalb der Tabelle oder in den Optionen, wer sie haben und damit arbeiten möchte, kann sie sehen und wer sie nicht braucht, macht den Haken raus und wird nicht durch sie beeinträchtigt.

Bei meinem Beispielbild wäre der Comment für die vier ELEX Dateien
"Run1 mit Overlay", "Run2 mit Overlay", "Run1 ohne Overlay" und "Run2 ohne Overlay"
In dem Fall würden mir schon die ersten 6 Zeichen ausreichen(z.B. "Run1 m"), um die Datei klar zuordnen zu können.

Aktuell gehe ich durch die Dateien durch, habe "Run1 ohne Overlay" an vierter Stelle gefunden und hinzugefügt und dabei schon wieder vergessen, welche der drei anderen Dateien denn jetzt "Run 2 ohne Overlay" war.
 
Zuletzt bearbeitet:
Zurück
Oben