Thank you. That's a great help. The left one is a version of an emulation application called Final Burn Alpha which has an Windows Aero Theme's microstutter fix. The right one is an older version that doesn't.
This is the same as the one on the right above but with some longer events (maybe from user interaction, or from loading textures etc) throwing off the vertical scale. BTW, you can adjust your charts to get a consistent scale for comparison - click in the left margin and play around a bit.
Looking at it again, maybe "terrible" is too strong. Frames times are oscillating between about 25 ms (40 virtual "fps" : 1/0.025) and probably half that (80 "fps"). This is common, especially if the system is nearing its limit. So how does it look to the human eye? My guess is that 60 fps with this amount of microstutter is roughly equivalent to a smooth 30-40 fps. Not *bad* looking, really - just not *quite* as smooth as true 60 fps.
Thank you again. The differences between all three are subtle in practice however it's for an online fighting games which are highly sensitive for execution / consistency, etc so micro stutter is a real problem more for the "feel" where you need to be able to execute inputs within sometimes only one frame of gameplay. The emulation requirements are basic - i.e. low load on the GPU and system overall. Instead it's from some aggravation with aero though I don't know the specifics. Again it's subtle but the build in the first image feels silky and consistent in comparison.
The last graph in the sequence. "Time spent above 33.3ms." Obviously, starting with a FRAPS frame time file , you could do an =SUM(A2-B2), etc, to arrive at the time between any two updates -- but how do you tell Excel to report the number of frames above 33.3ms in relation to the total number of frames?
Step 1: Make a "diff" column (formula = current time-previous time)
Step 2: Make a "diff-66.67" column for calculation purposes (I'm using 66.67, you can use 33.33)
Step 3: Make a "clamped" column that shows the previous value if > zero, or zero otherwise
Step 4: Get total time over 66.67
Step 5: Get total of all times (EDIT ...or just use the time of last frame...)
Step 6: Get the result as a percentage
Here is the data in Fraps Bench Viewer. You can see that 97% is about right. (I don't recall benchmarking Premiere Elements; it's possible I hit a hotkey by accident. There were probably long pauses with zero fps as I was thinking about some edit):
Ok you were right about the frametimes box, I had it unticked because I was only interested in the FPS, I only want the broad picture of what's going on, hence only FPS was ticked. Just did a quick run with it on, worked this time & got a nice detailed graph .
I was thinking that your program could graph the FPS.csv file but I see I was wrong, which means I can't graph my benchmarks , oh well nm.
I don't suppose it can be made to graph from the fps file can it? (I'm not after the micro detail you get from frames).
Btw I see the frametimes file is much bigger than the fps one! 216KB vs 1KB!
@plonk420 Unfortunately, raffriff is no longer an active contributor to this forum and does not post. Your message is almost certainly not going to be read, although he seems to log into the forums semi-regularly and may notice your message.
Indeed, in a given second, there were at least 155 frames rendered. However, not every one of these 155 were the same: some took longer to render than others.
What the low 1% and 0,1% show are the individual frames that took longer to render (in miliseconds) than others. Since we don't really interpret well in ms, it's easier to translate that number to fps. So 13 ms becomes 76 "fps".