VSync does not seem to adapt to the window changing between monitors of different refresh rates

[natanfudge]

Description
If you have a 144hz monitor, and a 60hz monitor, and you move the window from the 144hz monitor to 60hz monitor, the frame rate will stay at 144 fps.

Repro steps

1. Run the 02_hello_window sample, and add some code that tracks the time between frames, here is a full example:
   https://gist.github.com/natanfudge/fa88596706e51b6e55903c06d58e035d
2. Make sure to run the window initially on a screen with some refresh rate (e.g. 144) by setting that screen to be your primary screen.

Observe prints:

Time since last frame: 6.821ms
Time since last frame: 6.9617ms
Time since last frame: 6.8569ms
Time since last frame: 7.331ms

4. Move the window to a different monitor with a different refresh rate (e.g. 60)
5. Observe prints (same, with some small variation obv):

Time since last frame: 6.821ms
Time since last frame: 6.9617ms
Time since last frame: 6.8569ms
Time since last frame: 7.331ms

Actual Behavior
Frame rate stays at the initial one (144 fps, 7ms seconds per frame)
Expected Behavior
Frame rate adapts to the change in monitor and changes (to 60 fps, 16.6ms per frame)

Platform
Windows 11
wgpu 25.0.1

Extra Notes

• This behaves correctly with GLFW + OpenGL.
• I have tried solving this in many ways, reconfiguring surface, recreating surface, restarting window but I did not manage to make it work as expected.
• If there is some configuration that makes this work, please let me know (using GLFW)

[cwfitzgerald]

This isn't something in our control - which monitor is your primary monitor? The primary monitor determines the compositor's refresh rate. If you're not fullscreen you'll be running against the compositor's frequency, unless the compositor gives you an MPO plane.

[natanfudge]

@cwfitzgerald Considering the frame rate does adapt with a usual glfw + opengl setup, I would guess then that one of those libraries uses the MPO plane to provide the correct frame rate. If GLFW has the ability to do this, how do I instruct it to do this with wgpu? If OpenGL does this, doesn't that mean wgpu is supposed to do it as well?

And yes, the primary monitor is 144hz, and I expect wgpu to synchronize against the monitor that the window is in (or has the larger percentage), not the primary monitor.

[cwfitzgerald]

If GLFW has the ability to do this, how do I instruct it to do this with wgpu? If OpenGL does this, doesn't that mean wgpu is supposed to do it as well?

This is something that is decided by the compositor not the application. Vulkan drivers only recently making vulkan drivers able to be directly scanned out (i.e. implementing the vulkan swapchain on top of a DX12 "flip model" swapchain) and there has been back and forth if they are enabled. Your driver may be using a flip swapchain for gl, but not for your vulkan implementation.

You can look at presentmon (get the exe not the msi) to see how your window is interacting with the compositor. There's nothing we can do about this unfortunately, so I'm going to close the issue, but feel free to continue discussing this in the issue