Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimized emulator causes speedup of emulation #1279

Closed
Nicholas-Steel opened this issue Aug 16, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@Nicholas-Steel
Copy link

commented Aug 16, 2018

Vsync Throttle (tick)
Vsync Enabled (tick)

If I'm playing an N64 game than minimizing the emulator will cause the emulation to speed up. Switching to another application doesn't cause this phenomena, only minimizing does.

Windows 10 x64 1803
Geforce 760 (391.35)

@Asnivor

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2018

Confirmed. This actually happens on Win7, not just Win10. And only appears to be N64 at the moment (although I have only tested a couple of other cores)

@Asnivor

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2018

@zeromus

This happens because vsync and vsync throttle are only checked if JobInfo.offscreen is TRUE:

https://github.com/TASVideos/BizHawk/blob/master/BizHawk.Client.EmuHawk/DisplayManager/DisplayManager.cs#L750

So in this example if bizhawk is minimised, these things are never checked in UpdateSourceDrawingWork() (and so no throttling happens at all).

Is this expected behavior? I really don't know much about vsync. Will the world end if we attempt to vsync throttle when bizhawk is 'offscreen'?

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2018

This is caused by 3adc8f7
dont send 0-sized framebuffers deep into displaymanager (prevents crashes when sending fullscreen windows to other monitors sometimes, and probably other bugs)

			if (job.chain_outsize.Width == 0 || job.chain_outsize.Height == 0)
			{
				this has to be a NOP, because lots of stuff will malfunction on a 0-sized viewport
				return null;
			}

I probably thought it didn't make any sense to send 0x0 deep into displaymanager, so didn't investigate this deeply once I realized it would fix it.

However I see now that we might need to go all the way to the end, for purposes of making vsync work.

I'll rejigger this code a little bit, and I think it will fix this bug without affecting the old stuff.

@zeromus zeromus closed this in 14ad5a3 Sep 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.