Probably luck. This is one Reddit post with pointers to others:
But I’ve read in various credible Apple specific and general computer media about problems, especially with popular Apps that use the Electron framework as GUI toolkit. If just one such app runs, it will shred performance. The worst bugs seem to have been fixed in latest Electron releases, so it depends if all Electron apps are up to date enough to have the bug fixed. E.g., what Google search lists as troublemakers wrt. the Electron bug:
- 1Password (v8.11.14 and later included the fix)
- Bitwarden
- Cursor (an AI-powered code editor)
- Discord (since fixed)
- Dropbox
- Ferdium
- GitHub Desktop (since fixed)
- Logi Options+
- Loom
- MongoDB Compass
- Notion (Mail and Calendar apps; since fixed)
- Postman
- Slack (since fixed)
- Superhuman
- Visual Studio Code (VS Code; since fixed)
And there seem to be bugs specific to specific M chip generations, some M1, especially M4, which is what Keith has on his test machine. Some of these seem to have gotten worse with the 26.1 bug fix release, the status in the 26.2 beta is unknown.
That said, I looked at our license manager to see what kind of users and machine models already run macOS 26.1 or later. There are multiple users on each M1, M2, M3, M4 model variant, and so far we don’t hear reports of trouble by any of them except Keith with his M4. Your report is inconclusive, as the 10 bit bug is actually a PTB bug, already fixed in my Git repository, and the actual timing plots from you look as if timing might be ok’ish, and the missed frames might be caused by your machine having “Pro Motion” activated for its internal display ie. the special up to 120 Hz mode that won’t work with PTB at the moment, because it is a VRR mode that PTB does not support on macOS. Iow. unrelated to what Keith reported.
If general various outlets report that on many macOS 26 setups, GUI animations feel jittery or janky to a non-trivial number of users, something that could be caused by randomly or systematically dropping frames due to WindowServer bugs reported multiple times.
The WindowServer consuming 90% of all gpu resources certainly would not go well at all for any presentation and animation timing.
If the root cause for Keith problems would be a general macOS Tahoe bug affecting many other popular use cases, applications and general user experience, that would be a good thing, because then there would be an actual incentive/pressure for Apple to fix it. If it is something only affecting niche applications like vision science toolkits, I know how Apple “deals” with that, and it would be the usual sadness.
The problem with macOS for Apple Silicon is that with switching to their own proprietary AGX gpu and DCP display engine, and various other OS level changes, and an even tighter “security” lockdown, Apple has taken away most tools I had available in the past on Intel or PowerPC Macs to diagnose / fix / work around macOS bugs and deficiencies. And the vast amount of deep knowledge relating to Intel, AMD, NVidia gpu’s doesn’t transfer due to some very peculiar (to say it friendly) design choices Apple made with their proprietary DCP display engine and firmware. E.g., the PsychtoolboxKernelDriver which was/is absolutely instrumental and crucial for both diagnosing and fixing/working around issues on Apple PowerPC and Intel Macs, is an absolute no-go for Apple Silicon, it is permanently dead and unusable on macOS for Apple Silicon.
Just as in the past, the main source of useful / helpful low level knowledge comes from the Linux community, not from Apple resources: The Asahi Linux project is a group of technically highly talented volunteers, which want to bring Linux to Apple Silicon Macs. It includes (or should I say, sadly, included) some absolute top notch graphics reverse engineering geniuses with an insane drive to make Linux on Apple Silicon happen. However, reverse engineering only includes M1 and M2 SoC’s so far, so that doesn’t help much with potential trouble specific to M3 and later.