This is so weird! Regularly distributed over a run, not all or most at the beginning, and each time a vkWait… timeout error. This goes counter to pretty much any half way plausible mental model or prediction one can form about how certain types of more likely bugs can cause problems. And, again, different from how older macOS versions behave.
The vkWait… error happens when macOS Metal+CoreAnimation framework, or the macOS WindowServer aka Quartz display server, “scrambles” the order in which feedback about completed image presentations is delivered. Essentially PTB + the MoltenVK Vulkan driver tags each to-be-presented image with a unique serial number n and a target presentation time, hands it over to the macOS proprietary closed source Metal + CoreAnimation frameworks, then vkWait… waits for feedback from macOS/Metal that the image with this serial number n has been presented, and also with a timestamp of when that image has been presented. This feedback is run back through MoltenVK/Vulkan’s accounting and book keeping, then to PTB with its accounting and book keeping, checking etc. and returned as Screen('Flip', ...) stimulus onset timestamp.
A properly working graphics system will receive frame with tag n, process and display it at the proper time, or a bit later in case of overload or too late submission, then immediately after successful presentation will return the feedback to the Vulkan driver which finishes the vkWait… for tag n.
What every single macOS version before macOS 26 so far randomly did is scramble this sequence at random times for random unclear reasons, e.g.,
-
Submit frame n → vkWait for frame n → macOS does or does not actually present frame n, but in any case does not signal completion back. vkWait times out after one second, PTB gives up, prints a warning/error message, fakes a half-way plausible but still wrong timestamp, script goes on based on that.
-
Submit frame n+1 → vkWait for frame n+1, same sequence of failure as 1.
-
Submit frame n+2 → vkWait for frame n+2, macOS suddenly reports back completion feedback for frames n, n+1, and n+2, so now vkWait for n+2 completes successfully, and Vulkan/PTB throw away the stale feedback for frames n and n+1, process frame n+2 and successfully report proper timestamps etc. for frame n+2.
-
Now suddenly the process is unjammed, and everything works for frames n+3, n+4, …
-
So the user observes weird multi-second stutter and printed warnings and errors for the first few Screen(‘Flips’) and then suddenly things work smoothly…
-
…until they don’t, e.g., because there was a pause in stimulus presentation of at least 1 second and the system starts to malfunction and jam up again for a few frames, until it unjams, or forever because it never recovers at all.
None of this makes sense, except it being 100% a severe bug in macOS graphics and display system, which Apple never ever fixed, not since the mechanism was introduced in macOS 10.15 over six years ago. The error pattern varies between macOS versions, and sometimes between Intel Macs (where we don’t care much, as we have other and much more reliable “PTB unique” ways of fixing this - only all other toolkits are broken on macOS Intel) and Apple Silicon Macs - where there is no known simple, elegant, efficient, or even somewhat hacky way around this mess.
All these problems also happen with other applications, essentially with any applications that require any kind of half-way precise and reliable feedback about how image presentation went.
So “things jam up at the beginning and after long pauses in stimulus presentation, with vkWait… timeout errors” makes sense from the mental model of the brokenness of macOS.
macOS 26.0 added an additional problem: The system expects a new stimulus image targetting video refesh cycle m+1 to be submitted within fractions of a millisecond after start of video refresh cycle m, because the composition cutoff deadline of the WindowServer has been shifted from close to the end of a cycle to very close to the beginning of a cycle. So whenever an applications waits for feedback about present completion of a given frame for video refresh cycle m, it will only get that feedback at beginning of cycle m in the best case scenario, but then it will only have << 1 millisecond to prepare, render and submit the next stimulus frame targetting cycle m+1. Less than 1 millisecond is almost never enough time for all the needed processing, and so the composition deadline is missed and the frame targetting m+1 will not display at m+1 but only one cycle later at m+2 and you have a missed Flip deadline → Now each Flip takes at least two video refresh cycles and the maximum achievable presentation rate is cut into half the video refresh rate of your display, iow. maximum 30 fps on a 60 Hz display. These were my results of testing macOS 26.0 and 26.1 on a M1 MacBookAir for over a week in December with every diagnostic tool I had available, and comparing behavior to macOS 14 and macOS 15 on the M2 Pro MacBookPro and macOS 13 on the 2017 Intel MacBookPro with AMD graphics.
I assumed this shifting of the composition deadline was intentionally done by Apple, not a bug in the strict sense, to hide or reduce severe performance problems caused by macOS Tahoes new (and well hated by many, including myself) “Liquid Glass” GUI. The Liquid Glass UI puts substantially more load and stress on the gpu and graphics drivers, and can more easily overwhelm a relatively weak integrated gpu like the ones used in Apple Silicon Macs, causing slow downs, sluggish UI behavior, stuttering animations and reduced runtime on battery. Shifting the composition deadline to the beginning of a cycle would hide or reduce the effects of these performance problems, while at the same time only really punishing applications that need precisely controlled visual presentation timing, or exact audio-video sync in some specific scenarios. Other run of the mill interactive apps would only be affected in a way that is not too perceptible by Joe average user. If this assumption is true then it would be a no win scenario for any properly working vision science toolkit, as you can only have either precise timing control, or performance, but not both.
So your results now suggest that Apple changed or “fixed” something sometimes between macOS 26.2 and macOS 26.4 (according to Peters results) or macOS 26.5-beta (according to your results), and the composition deadline may no longer be nailed to the beginning of a frame, which is somewhat better for us (a glimmer of hope), but at the same time they might have broken yet another thing, because the new error pattern doesn’t match any of the previous patterns, or diagnostic results, or my mental models of brokenness.
Having skipped frames in the middle of runs is usually a sign of temporary load changes or resource shortages, and having them on slower running animations (for w > 1 cases in your tests) can be a sign of gpu dynamic power management interfering in very unwelcome and suboptimal ways. But for skipped frames in the middle of otherwise continuous animations, with vkWait… 1 second timeouts would be something entirely new with no good explanation at all.
It’s a jungle out there. Not sure if more feedback or testing helps right now. This testing was useful though, as just something additional to take into account in this zoo of macOS display absurdities. Keep it coming if you learn something new with a future macOS release, much appreciated!
My own dedicated “high risk work” machine for Tahoe testing is literally an island away right now with my girlfriend, out of reach for direct hands on testing probably for a couple of months, and I can’t risk upgrading the M2 Pro MBP from macOS 15 atm., until I’ve found a solution to the pre-Tahoe macOS problems that establishes a new baseline to reliably work from. There is one possibly effective idea left for dealing with macOS timing problems, but it is complex and time consuming to implement and test, and it is based on other pieces of work from Linux land that first need to fall into place, and it needs macOS 13 and 15 as baselines first. So not all hope is lost, but it will take considerable time until that is ready for testing. And it may or may not work on macOS 26 even if it would work on earlier versions of macOS.
Atm. and for the last 8+ months everyone and everything, from Apple, to NVidia and AMD on MS-Windows, to “the Linux ecosystem in general”, to our online shop / reseller FastSpring, is throwing software-, process-, policy- and business obstacles in my way, I really feel like being locked into a jump and run game. So expect a lot of slow or even negative technical progress and depressing outcomes in the next months, because apparently nothing can ever go right ever for more than a month or two per year, just long enough to create a false illusion of cautious optimism…
!
