There has been at least one report of macOS 10.13 / 10.14 adding an extra one frame delay to graphics update times, causing experiment software graphics update times to be off by one retrace.
We used the MilliKey DeLux light sensor to look into this further by testings the display change timing of a macmini running either macOS 10.9.5 or 10.13.6 connected to an LCD display. Sure enough, it looks like sometime between macOS 10.9.5 and macOS 10.13.6 an extra one frame delay has been added to the operating systems graphics pipeline.
The computer monitor and test script were the same as was used in the Windows 10 Display Timing post. Unless otherwise stated, this test used the same procedure as that post.
In this test we used was an Apple macmini (late 2011 model) connected to a SyncMaster P2770 LCD monitor. The stated response time of the SyncMaster P2770 is 1 msec, which probably means it is closer to 2 msec peak to peak.
The same test script was run on the same hardware while booted into either macOS 10.9.5 or macOS 10.13.6. The time difference between receiving the DeLux USB serial trigger event and the time reported from the win.flip() for each dark-light transition was calculated, subtracting the 7 msec offset the DeLux was configured to use.
USB serial events sent by the MilliKey DeLux will add an average of 0.5 msec to these display change delay results. This has not been corrected for in the following plots.
While using macOS 10.9.5 we observed an expected / reasonable display update delay for the LCD monitor being tested. Average
Results show a consistent 1 frame delay in macOS 10.13.6 display updates as compared to macOS 10.9.5.
Using a MilliKey DeLux light sensor we have been able to show that there does seem to be an extra frame delay in display update timing on macOS 10.13.6 (or higher presumably) that does not exist in macOS 10.9.5. This adds an extra one retrace delay to any screen update times calculated by the experiment. This means visual stimulus duration should still be accurate, however onset and offset times should both be corrected for the extra delay.
If anyone is aware of a way to fix this issue on macOS 10.13+, please let us know.