Emulator

This sounds nice in theory but I find this would be very difficult to pull off with Dolphin's current architecture and I question the value given the complexity it adds.

When Dolphin stutters it doesn't lose any frames from its perspective. So we can't really ask it for missed frames.

If there is shader stutter, we could possibly determine roughly how much time the shader took to compile but it would be a rough estimate. But let's say we had that, we'd have to somehow convert that to a number of frames missed. Then we could try and estimate how much speed we'd need to move forward. This speed up would have to be tracked, either by time or a frame count. Neither would be exact and users might speed past scenes they want to see unintentionally.

We already have options for handling shader stutter in general, so my personal viewpoint is rather than all this complexity, users should use those options.

Yeah, "losing frames" isn't the best description of the issue.

When dolphin has a shader compilation stutter it's going to fall behind compared to other wiimmfi/netplay users that are not stuttering.
It will continue to fall more and more behind in overall emulated game time with each stutter, even if the host computer is otherwise capable of emulating well over 100% speed normally.

This wouldn't be hard to fix.
We already know how long each frame is supposed to last and induce a delay to maintain the desired frame rate.

Compare the overall should-be emulated console runtime to a monotonic clock of the host to fudge that "delay" and continuously approach the proper total emulated console runtime since emulation start.
Pause/Resume will have to adjust the timings, of course.

Hmm it might be fine but I guess my concern would be that it is prone to error. We are going to wait a specified time based on how long we expect a frame to last, not based on how long the frames are actually taking? That feels like that could break very easily and will only work if the users CPU is able to keep up and that's assuming our timing matches reality.

Anyway, if we aren't going to measure/track frames, then I'm less concerned with potential complexity. I still think users should just use the shader stutter mechanisms we have available (and if there are flaws, report them) than try to work around the issue. But if someone wants to implement this, they can.

Even if stutters can be eliminated entirely, our current approach of, "hopefully all these ~16.66ms frames add up to the overall proper emulation time", is probably not ideal for NetPlay or wiimmfi.

After looking at the existing code, particularly CoreTimingManager::Throttle, the logic to maintain the overall correct progress actually already exits, but it's written to effectively ignore this if the system strays more than 100ms of where it should be.