"Unthrottled" setting burns cpu when paused

[Morilli]

Unthrottling the speed and then pausing the emulator seems to burn cpu by having one thread continuously looping through some code and never being throttled.

Interestingly, this even works in the null emulator: Simply starting up bizhawk, checking "unthrottled" and then pausing should show this issue.

Did a git bisect, and it blames 007442773a35c213257f8462b2b948bdddefe5fa (lol).

[getCursorsExe]

This issue is invisible at first, but you'll see this when you open Task Manager.

[Morilli]

Thoughts on this?

diff --git a/src/BizHawk.Client.EmuHawk/MainForm.cs b/src/BizHawk.Client.EmuHawk/MainForm.cs
index 2dbc0b6f1..f1e45e0b2 100644
--- a/src/BizHawk.Client.EmuHawk/MainForm.cs
+++ b/src/BizHawk.Client.EmuHawk/MainForm.cs
@@ -2983,7 +2983,7 @@ namespace BizHawk.Client.EmuHawk
                        SyncThrottle();
                        _throttle.signal_frameAdvance = _runloopFrameAdvance;
                        _throttle.signal_continuousFrameAdvancing = _runloopFrameProgress;
-                       if (_lastFastForwardingOrRewinding) _throttle.signal_paused = false;
+                       if (IsTurboing) _throttle.signal_paused = false;

                        _throttle.Step(Config, Sound, allowSleep: true, forceFrameSkip: -1);
                }

Still shows the mentioned behavior when holding the turbo hotkey, but that shouldn't be much of an issue imo.

edit: welp, that seems to rewind too fast without turbo then... there's too much logic interfering with everything here for me to understand why...

[vadosnaprimer]

What if you only check for rewind and FF rather than rewind or FF?

[Morilli]

I think the issue is that this isn't possible currently; the _lastFastForwardingOrRewinding is never false when being in a paused state while unthrottled speed is active, and I couldn't find other variables that basically say "we are rewinding currently".

[vadosnaprimer]

I discovered another example of this. If I enable turbo seek in tastudio and advance a single frame, a whole CPU core gets maximum busy, and is only released if I disable turbo seek and advance once more. I really don't believe we need this behavior, because turbo seek is meant to only ever affect seeking, not idling.

[zeromus]

Without diving too deeply into this but just thinking about it from a purely logical point of view, it would seem like we should do this: _lastFastForwardingOrRewinding = false; just before if ((runFrame || force) && !BlockFrameAdvance) can someone try that, especially @vadosnaprimer in the complex tastudio test? It just looks like a typical scenario of "logic depends on 'last' value being correct, but 'last' value only updated by some cases; fix it by guessing what's the meaning of 'last' for all other cases and let 'some' cases correct it"

[Morilli]

@zeromus your suggestion does nothing except disabling the fps display, as _lastFastForwardingOrRewinding is set again afterwards.

[vadosnaprimer]

I can't test it because I didn't have time to resolve my build problems with nuget, but by the nature of tastudio's turbo seek, UI updates should instead be minimal, so that all the power is invested into how fast it's emulating. And due to how wrong the current behavior is, I think this issue needs more attention.

Pinging @zeromus once again to reply to the above comment.

[CasualPokePlayer]

Oddly, this issue doesn't actually burn much CPU for me, however it absolutely burns through the GPU, raising it up to 100% usage often