From 864d41951315d28241d754f93a787218290a6047 Mon Sep 17 00:00:00 2001 From: rogerman Date: Mon, 18 Apr 2022 14:54:54 -0700 Subject: [PATCH] Cocoa Port: Use [MTLDrawable present] instead of [MTLDrawable presentAtTime:]. Does this reduce microstuttering even further? --- .../cocoa/userinterface/MacMetalDisplayView.mm | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/desmume/src/frontend/cocoa/userinterface/MacMetalDisplayView.mm b/desmume/src/frontend/cocoa/userinterface/MacMetalDisplayView.mm index 5f8ea5187..bf7a305b1 100644 --- a/desmume/src/frontend/cocoa/userinterface/MacMetalDisplayView.mm +++ b/desmume/src/frontend/cocoa/userinterface/MacMetalDisplayView.mm @@ -2392,7 +2392,21 @@ [cb addScheduledHandler:^(id block) { @autoreleasepool { - [drawable presentAtTime:(CFTimeInterval)outputTime / 1000000000.0]; + // Let's try [MTLDrawable present] instead of [MTLDrawable presentAtTime:] in + // an effort to reduce microstuttering even further. Testing on various Metal + // machines shows a minor, but still slightly noticeable, reduction in + // microstuttering. + // + // This probably works because this method is called in response to a + // CVDisplayLink output callback, which is already expecting to see a frame + // very very soon. [MTLDrawable presentAtTime:] does have a little more + // overhead than [MTLDrawable present], and so it is possible that the former + // method might be pushing the rendered frame ahead by up to 2 frames, whereas + // the latter method will always push the rendered frame at most 1 frame ahead. + // This best explains the observed behavior in certain rendering scenarios. + + //[drawable presentAtTime:(CFTimeInterval)outputTime / 1000000000.0]; + [drawable present]; if (drawable == [self layerDrawable0]) {