Skip to content

Macos latency fix#15279

Draft
alexgu754 wants to merge 2 commits intolibsdl-org:mainfrom
alexgu754:macos-latency-fix
Draft

Macos latency fix#15279
alexgu754 wants to merge 2 commits intolibsdl-org:mainfrom
alexgu754:macos-latency-fix

Conversation

@alexgu754
Copy link
Copy Markdown

@alexgu754 alexgu754 commented Mar 27, 2026

Description

A very bad attempt to improve latency. By adding extra waits to 'WaitForSwapchain'. Any Mac users out there? Please tell me what you see on your machine when dragging imgui windows https://github.com/ocornut/imgui/tree/master/examples
I guess if you have a 120hz display, the frame lag is less bad

What's Implemented

  • Attempts to estimate your work
  • Wakes up early so you can finish your work in time for displaylink
  • The command buffer is passed to the displaylink callback because for some reason, it doesn't present in time if you submit early (before the callback), even when atTime is provided (or maybe I'm doing something wrong?). So to not block submit, its given to that thread
  • Skips frames until the previous frames are presented, or if the swapchain fetch is long, so you know your requested swapchain will be presented next (can be made to match MaxFramesInFlight I guess)

Is this worth pursuing? Or should mac users give up and deal with the lag like how it is for most apps
Does anyone know what's the 'correct' way to implement this so you get the smoothness you see in chrome and safari? Because a simple [NSApp run] with DrawInMTKView alone doesn't work, since it doesn't track swapchain usage and it ends up looking exactly like how while(!quit) { draw_metal(); frame(); } does, and I guess most applications don't want to go the conventional NSViewController route and want their own while loop

you can check out the feel for yourself, video doesn't do it justice, github seems to reencode it and lower the framerate
https://github.com/alexgu754/LowLatencyOSX/tree/main
https://github.com/user-attachments/assets/34137caa-4eea-4ee3-a223-f4802993fb5f

Issue #14456

Before, MetalFence was implemented as simply a busy loop on an atomic
int on metal, meaning the cpu would busy wait on the gpu to finish
taking power from it and decreasing battery life. This was the only kind
of cpu-gpu syncing (apart from requesting a swapchain)
not exactly sure how its supposed to work. Very rough prototype
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.

1 participant