Constant 60 FPS but annoying micro-stuttering

Support for running, installing or compiling OpenMW

Before you submit a bug report for the first time, please read: Bug reporting guidelines
User avatar
Posts: 4692
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile:

Re: Constant 60 FPS but annoying micro-stuttering

Post by psi29a » 28 Nov 2018, 13:49

AnyOldName3 wrote:
28 Nov 2018, 13:45
We do fixed timestep with interpolation for the physics, but that's not something applicable here - you need to know which two things to interpolate between, which involves knowing the expected time that the next frame will be displayed, which is the whole problem in the first place with that type of stutter.

If we take a running average of frametimes, that would help reduce the impact of one frame taking an unexpectedly long time, but would also mean that one frame affected even more frames than it does now. Overall, it might be good and it might be bad.
That's the whole point of NV_present_video, if gives you that expected time of the next frame. The Vulkan equivalent is VK_GOOGLE_display_timing. ... _video.txt
It also allows an application to request when images should be displayed, and to obtain feedback on exactly when images are actually first displayed.
So for people have the supported extension in their hardware and software stack, we can then solve this particular issue.

User avatar
Posts: 338
Joined: 09 May 2015, 13:07

Re: Constant 60 FPS but annoying micro-stuttering

Post by wareya » 28 Nov 2018, 16:31

Microstuttering is basically a framerate pacing issue. It caused by anything: overly aggressive power management, large VRAM <-> RAM transfers, etc. It can also be caused by physics taking way too long, but happening at 30hz or 20hz instead of 60hz. How it manifests depends on where during the input->rendering->display pipeline it happens, how physics-rendering synchronization works, whether the user has a high-refresh-rate monitor or not, and whether vsync (even GL-style triple buffered vsync) is being used for anything at all.

Assuming you somehow have completely correct delta time that predicts exactly how long it's going to take for the current frame to end up on the screen after the last one (so each frame finishes rendering exactly in sync with the physics timestep it represents), you're still going to suffer if you're on a 60hz display and the game is running at 60fps, and it won't feel like 60fps no matter how hard you try or how hard the refresh rate of your monitor is. (In reality this prediction is going to be wildly wrong, or you're not going to try to predict it and you're going to use the last frame's cycle time for the current frame's delta time)

On the other hand, if you render every frame exactly 16.67~ms apart, and display them with a flip queue and vsync so they always come out at exactly the same time, then you get huge input latency inconsistency depending on how long it actually took for that frame to end up on the display after its inputs were taken.

Fixes for one type of microstuttering can and will make others worse.

Smoothing out delta time over a two-frame window is a quick and dirty way to smooth out some kinds of stuttering while affecting as little other stuff and making as few assumptions as possible. It even smooths over timer inaccuracies. The only problem is that it can cause "warping" if it's too extreme or the framerate dips too low while also being very inconsistent.
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Constant 60 FPS but annoying micro-stuttering

Post by i30817 » 28 Nov 2018, 17:13

psi29a wrote:
28 Nov 2018, 09:39
If that was the case then disabling the script (or the mod) would 'resolve' the issue right? This isn't the solution but it is a way narrow down if that is indeed the root cause.

I've not seen any concrete ways in this thread to reproduce the issue. Not everyone sees this issue.
Actually a old trick used in java swing was to measure the time between eventqueue operations in their event dispatch thread (because to use swing you usually interacted with listeners that used the EDT). It was handy to find outliers, even if the listener programming model actually sucked.

It was easy to find misbehaving operations or EDT 'violations' (interacting with a swing widget outside of the EDT) because there was a single point to test if the widget was running in the EDT or a event was taking too long, so you wrapped the class that dispatched events and tested for those things.

From what little information I have about openmw this doesn't apply except maybe for scenegraph operations, which probably aren't relevant but it's a thought. You could maybe find outliers in scripts in the interval before and after execution.

But since the mod complained of is a texture mod... uh, this is probably not relevant. And for a openmw script to get that bad... did you know that until last week i didn't know that it had a while?

edit: the post above is better informed about this than my wild guesses about scripts.

Post Reply