Maybe see if this gives you the correct results: https://stackoverflow.com/questions/50236214/arkit-eulerangles-of-transform-matrix-4x4 If you just want an Apple API that does it, you could do it with a SceneKit node:     SCNNode *temporaryNode = [SCNNode node];     temporaryNode.simdTransform = rightEyeTransform;     SCNVector3 euler = temporaryNode.eulerAngles;     NSLog(@"%f %f %f", euler.x, euler.y, euler.z);

just to be sure, totally freshly nuked macOS 13.3 install and this is definitely still happening.

disabling ProMotion, setting refresh rate to 60Hz can sometimes lead to a functioning-as-expected state: but it's like rolling dice, other times framerate oscillates so that it looks like it locked to 40 Hz: a big factor seems to be: are other UI elements composited on top. while hovering the mouse cursor on the top screen edge so the menu bar becomes visible, for example, the stuttering goes away.

I have tried skipping MTKView altogether, using CAMetalLayer and a CVDisplayLink in a NSView subclass, replicating the MTKView functionality. The results are exactly the same. to recap: if the window is not in fullscreen, the displayLink and presentDrawable work together in lockstep as they should, giving stable 60Hz (or 120Hz). if the window is in fullscreen, there is some massive issue where whatever happens in presentDrawable can't keep up with the displayLink enabling or disabling ProMotion only has an effect on how the issue presents. The issue is present in both modes depending on what is rendered on screen, and how sensitive you are to the resulting stuttering, you may not see the effect with your eyes try rendering a something with sharp edges that moves steadily across the screen, behold the jittering the issue does NOT occur on my olde intel Macbook Air it's easily reproducible and I can't make it go away on my M2 Max Macbook Pro

but the frame pacing is solid when not in full screen. it's even solid when in full screen but with the menu bar visible. see this slo-mo video: https://www.youtube.com/watch?v=-YPRlnTc2K0 note how rendering starts fluid with the OS rendering the menu bar, but then starts to wonk out as soon as we are really full screen. So this is clearly an error. I'm currently finding that on Ventura, this is borked (will remain borked?). On Sonoma, it's relatively solid, with the exception that if ProMotion is enabled, and you set MTKView preferredFramesPerSecond to 60, it's very jittery (and with the same feature that if some other UI element is rendered over the fullscreen view, the error subsides).

the tumbleweed speaks