Skip to content

Throttle framerate when V-sync is enabled but window is not focused.#18826

Merged
LibretroAdmin merged 1 commit intolibretro:masterfrom
Clownacy:patch-1
Mar 19, 2026
Merged

Throttle framerate when V-sync is enabled but window is not focused.#18826
LibretroAdmin merged 1 commit intolibretro:masterfrom
Clownacy:patch-1

Conversation

@Clownacy
Copy link
Copy Markdown
Contributor

@Clownacy Clownacy commented Mar 14, 2026

RetroArch hogs an entire CPU core when running in the background with V-sync enabled. It seems that when the window is fully obscured by other windows, V-sync ceases to work, allowing RetroArch to run at an unlimited framerate, thrashing the CPU (and making my laptop very loud and hot).

As a workaround, the framerate is now throttled when the window is not in focus. I would rather have it throttle when the window is not visible, but there does not seem to be a way of detecting that.

Note that this is only known to be the case on Windows: I do not know what the situation is for Linux and other operating systems, though macOS does apparently suffer from this exact same problem, according to this SDL issue.

For the unlimited framerate issue to occur, the video driver must be Direct3D11, OpenGL, or Vulkan, 'pause on focus loss' needs to be disabled, V-sync needs to be enabled, and VRR needs to be disabled. If this is not enough to reproduce it, I can try to provide more information.

If anybody knows a better way to mitigate this issue, please let me know.

RetroArch hogs an entire CPU core when running in the background with V-sync enabled. It seems that when the window is fully obscured by other windows, V-sync ceases to work, allowing RetroArch to run at an unlimited framerate, thrashing the CPU.

As a workaround, the framerate is now throttled when the window is not in focus. I would rather have it throttle when the window is not visible, but there does not seem to be a way of detecting that.

Note that this is only known to be the case on Windows: I don't know what the situation is for Linux and other operating systems, though macOS does suffer from this exact same problem, according to this SDL issue:

libsdl-org/SDL#4521
@LibretroAdmin
Copy link
Copy Markdown
Contributor

Hi, this sounds great. Let me try to ask someone who is quite familiar with the runloop to give this a quick look. Thanks!

@LibretroAdmin LibretroAdmin merged commit a3052c9 into libretro:master Mar 19, 2026
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants