Periodic frame stutters on macOS in borderless mode

[luma0724]

Type

Game behaviour

Bug description

During gameplay of non-sv (slider velocity) beatmaps in mania, the notes that flow down suddenly "accelerates" with the timing of notes unmatched, and then "decelerates" to match the timing back (see 0:10-0:12 of the screen recording)

This game behavior can consistently reproduced on my machine on any maps under any graphics setting. (Please request me to test under different settings, I'm willing to provide more screen recordings) Settings used in the screen recording:

• Borderless
• Renderer: OpenGL
• Frame limiter: 2x
• Threading mode: multithreaded
• Hardware acceleration disabled

Testing on: Macbook Pro 16 inch (2023) with M3 Pro chip, 36 GB Memory OS: Sonoma 14.1

Update: this behaviour can occur several times in a gameplay and always at the same time if you retry the same beatmap.

Screenshots or videos

https://github.com/user-attachments/assets/aa4c32b5-89bf-484a-84cf-d5ee75a66a53

Version

2025.424.0

Logs

compressed-logs.zip

[smoogipoo]

It doesn't come out well on video, but I can actually reproduce this.

[luma0724]

The update time is consistently 2.2ms for me during the game play, and I am certain this is not a lag spike as there is no loss to frame rate. Unlikely to be a graphics issue specific to macOS

[smoogipoo]

I looked into this one and the issues are most prevalent in borderless (i.e. macOS's green fullscreen button), and not while windowed or exclusive-fullscreened. The spikes seem to evade our frametime monitoring for some reason, but they're easy to see with MTL_HUD_ENABLED=1:

https://drive.google.com/file/d/1QdGEg5qlm_SXp9vgY22N0jMvrrHkAwgM/view?usp=sharing

Notice:

• The spikes every 0.5/1s.
• That frame time is perfectly smooth once mouse input starts.

This does not seem to happen in windowed mode or "exclusive fullscreen" (turns out macOS does actually have this - it changes the rendering mode from "Composited" to "Direct"). You can enter fullscreen by pressing F11.

For now, I would recommend either using windowed or exclusive fullscreen.

I haven't found the reason for this, but I investigated two potential paths:

1. Adjusting our usage of CVDisplayLink to render in-line. Right now we use mutexes to synchronise between the display link and the draw thread, introducing potential scheduling/thread delays - maybe we are periodically missing the vsync interval?
2. Even with the above, I noticed that we're blocking on nextDrawable, which is something that really shouldn't happen with proper frame sync. The idea is that basically CVDisplayLink gives us a callback close to VSync time but doesn't prevent backpressure (i.e. it makes no effort to ensure a frame is available for write). I added a semaphore that forces only 3 in-flight frames.

However, none of the above seems to help at all. Those changes can be found here (nowhere near in a PR-able state, even if good in theory): https://github.com/smoogipoo/veldrid/tree/macos-render-on-displaylink-callback https://github.com/smoogipoo/osu-framework/tree/macos-render-on-displaylink-callback

So I'm a little bit lost now. We could try using CAMetalDisplayLink, but there was a reason I didn't use that previously, and I'm not entirely sure how to implement that immediately (need to read docs/etc). Also there's nothing indicating this would change anything other than clutching prayer beads based on naming alone.

I can't find anyone else with this exact issue, though there are blog posts with similar-looking issues out there. Of course, I've also investigated the way in which Veldrid presents and everything looks to be as optimal as possible.

[luma0724]

I can confirm the blog post is relevant. On my another Macbook Air M1 running on the same setting (borderless) there are no periodic frame slutters.

[smoogipoo]

Not sure what you're able to confirm from that blog post. To clarify: I've already gone through the blog post and I see nothing in there that we're not already doing.

Also, all of my testing was done on an M1. I do not expect there to be any difference between the two except software installed - for example: simply having OBS open will eliminate the stutters too. If you're not seeing any stutters then it is likely some other process interacting with macOS in some way that eliminates the stutters.

[peppy]

If you're getting consistent stutters every n milliseconds or seconds, the issue is that apps at a system-wide level can cause stutters in GPU. Start by closing everything, including things in the menu bar (especially these). Then figure out which app is causing the stutters.

I've had this happen with three different apps. My resolution was to stop using said apps.

Note that I can see such stutters in things like safari scrolling, when it occurs.

[luma0724]

If you're getting consistent stutters every n milliseconds or seconds, the issue is that apps at a system-wide level can cause stutters in GPU. Start by closing everything, including things in the menu bar (especially these). Then figure out which app is causing the stutters.

I've had this happen with three different apps. My resolution was to stop using said apps.

Note that I can see such stutters in things like safari scrolling, when it occurs.

That isn't the typical frame stuttersthat is solved by identifying the app that causes the stutters. It's a frame stutter that is solved by turning on OBS / Discord streaming 😂

[smoogipoo]

If opening OBS fixes it for you too, then it is exactly as I've said. For other commenters, please read my original reply which goes into quite a bit of depth and background knowledge that I can assure you is worth having.

I think it's fine for this issue to remain open as a tracker, but I don't have an immediate or even presumptive fix.

[peppy]

That isn't the typical frame stuttersthat is solved by identifying the app that causes the stutters. It's a frame stutter that is solved by turning on OBS / Discord streaming 😂

Can you please confirm you tested this? Also why are you using the GL renderer?

@smoogipoo are you also reproducing using GL? also might be worth noting that OBS has a setting (which I believe defaults to on) that disables vsync at an OS level while open.

I would be asking the original poster to post a video containing the frame graphs visible (Ctrl+F11) and using the metal renderer before confirming this is the same issue (reproducing across two renderers) and being a metal implementation issue at our end.

[smoogipoo]

The user's logs show they've been switching back and forth between OpenGL and Metal, likely to diagnose the issue. It appeared to me they're aware of this by explicitly mentioning it in the OP. I don't care much for OpenGL on macOS so all of my testing has been on Metal.

Though, OpenGL is likely the reason OP messaged me on Discord letting me know they can reproduce in exclusive fullscreen and windowed, while I can only reproduce on borderless (macOS maximised mode).

[smoogipoo]

@luma0724 Can you try System Settings -> Control Centre -> Automatically hide and show the menu bar -> Always?

[luma0724]

Wasn't on track of this issue for two weeks since I was on my trip. As an active player I couldn't play my favorite game since I was seriously affected by this issue (my profile)

I'll continue with some testing, will send a video using metal renderer + frame graph + metal HUD + borderless mode showing the issue (but interestingly I noticed in metal HUD the "Pre" blue line is almost straight showing no frame stutters, but I'm still experiencing the "acceleration" and "deceleration" issues as I described when I first opened the issue)

[luma0724]

https://drive.google.com/file/d/176YLjUmxrtUYxMoAbYmxJypKXRPq5zkr/view?usp=sharing

I recorded with MacOS default method (so it's 30 fps and poor quality). Also I would not describe the issue seen in the video as frame stutters, really, as there is no pause etc. and the game runs smoothly and the graph indicates, but just the weird "accelerate" and "decelerate" issue (which is the most obvious, even at 30 fps recording, at the timestamp 0:54)

(I'm gonna set up OBS and try to record better quality video, though I think the same issue is shown clear enough in the video I posted when I opened the issue)

Btw I have two macs on my hand and this issue never happens on my M1 air, from a user POV I suspect it's a promotion issue with mac, gonna test it later on the m3 pro setting on 60 fps fixed)