I think it also gets worse if you have multiple applications drawing to the screen using 'accelerated' APIs like Metal or OpenGL. My hypothesis is the CVDisplayLink, CAMetalLayer and CGDisplay presenting the view are not congruent, however, it is unclear if it is even possible to manage all this within user code. During initialization, a single call was made to CVDisplayLinkSetCurrentCGDisplay, however, moving the window between displays did not result in further calls to this API. I hit a call to CVDisplayLinkCreateWithActiveCGDisplays during initialization of the MTKView. Debugging the minimal front end, I added a symbolic breakpoint to determine how the CVDisplayLink was created for triggering the drawInMTKView.
#Using tinkertool to optimise framerate in mojave update#
I don't yet know if this is a macOS issue or whether I would need to manage my own CVDisplayLink timer and constantly update which CGDisplay it is associated with.
When I limited macOS to a single display, there is no stuttering. This too had frame stuttering issues when multiple displays are connected. To eliminate any issues with RetroArch itself, I ended up creating my own minimal libretro front end and using MTKView's drawInMTKView, which is synchronized with a CVDisplayLink timer. I added Metal support to RetroArch, a popular open source game front end, and have been troubleshooting an issue where the frame rate will periodically drop below 60fps, causing frame and audio stuttering. When using either CAMetalLayer.nextDrawable or MTKViewDelegate's drawInMTKView: APIs, a consistent 60fps does not seem possible when multiple displays are attached to macOS.
0 kommentar(er)
