Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flickering on M1 Max macbook (metal backend only) #102

Closed
Tom94 opened this issue Jan 11, 2022 · 7 comments
Closed

Flickering on M1 Max macbook (metal backend only) #102

Tom94 opened this issue Jan 11, 2022 · 7 comments

Comments

@Tom94
Copy link
Contributor

Tom94 commented Jan 11, 2022

Hi Wenzel, I've started experiencing sporadic flickering when using the metal backend on my new M1 Max macbook; see the following video.

I've made the following observations:

  • the behavior is independent of the screen. I can reproduce it on external LDR monitors connected to the laptop and all resolutions / refresh rates.
  • it appears to only affect example1 and tev, whereas for the case of tev it only affects the screen region covered by a canvas. example4 is not affected, even though it involves a canvas -- so nesting the canvas inside of a window appears to work around the problem somehow.
Screen.Recording.2022-01-11.at.17.12.18.mov

Cheers,
Thomas

@wjakob
Copy link
Member

wjakob commented Jan 11, 2022

Hi Thomas,

thank you for the report. Very puzzling. I will look into this, but it probably won't be until I receive my own M1 machine (ETA: February 1).

Wenzel

@wkjarosz
Copy link

As an extra data point: I've also noticed similar behavior on my M1 Max MacBook Pro using the precompiled binaries of HDRView, but haven't had any time to investigate.

@piotrkundu
Copy link

I can have a look when I get to my M1, but did run it a few hours ago and didn't notice flickering - but I wasn't looking hard enough

@zzambia
Copy link
Contributor

zzambia commented Feb 5, 2022

Confirmed on MBP14 M1 Pro - Monterey 12.1 Metal backend. Used Display menu to test at different refresh rates, it seems replicable only at ProMotion 120Hz.

@wjakob
Copy link
Member

wjakob commented Oct 21, 2022

Hi everyone (+ping @Tom94, @wkjarosz),

lots of time later, I finally had a moment to look into this (sorry!). It's been tricky to debug this because the flicker is not easy to reproduce reliably at least on my machine.

Could you let me know if the following simple nanogui patch fixes the issue on your side?

diff --git a/src/darwin.mm b/src/darwin.mm
index 7d9a886..83d448f 100644
--- a/src/darwin.mm
+++ b/src/darwin.mm
@@ -113,7 +113,7 @@ void metal_window_init(void *nswin_, bool float_buffer) {
         layer.pixelFormat = MTLPixelFormatBGRA8Unorm;
         layer.colorspace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB);
     }
-    layer.displaySyncEnabled = NO;
+    layer.displaySyncEnabled = YES;
     layer.allowsNextDrawableTimeout = NO;
     layer.framebufferOnly = NO;
 }

@Tom94
Copy link
Contributor Author

Tom94 commented Oct 22, 2022

It does -- although it's interesting that disabled VSync would cause flicker artifacts beyond tearing. Thanks for the fix!

Tom94 added a commit to Tom94/tev that referenced this issue Oct 22, 2022
@wjakob
Copy link
Member

wjakob commented Oct 22, 2022

Ok, that is great to hear. From what I can gather in the documentation, that flag changes the render pipeline quite a bit and has things go through CoreAnimation. So it's likely that other forces are at play beyond simple tearing etc. as you mention.

@wjakob wjakob closed this as completed in 16f8b4d Oct 22, 2022
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

No branches or pull requests

5 participants