@_qx1147 explains the meat of it quite well. Let me add a few things, hopefully not being all too repetitive:
Triple-buffering as a hazard can be replaced by n-buffering with any n ~= 2. Different versions of different operating systems, or of the same OS can change n or even change n dynamically depending on various factors.
Even for pure triple-buffering, there isn’t necessarily a one frame extra lag. That may, e.g., not happen on a first flip after some multi-frame pause, as the display system is idle and can just flip your current frame to the display, as your “just flipped” frame is at the head of the wait queue. If your applications renders and flips faster than video refresh, the triple buffering will kick in and add a one frame delay, as “flipped” buffers queue up in a waiting queue. If your applications slows down or pauses a tiny bit at some point in time, the wait queue may run empty again and the next flip will be back to displaying immediately. So you might alternate between 1 frame extra lag and no extra lag. Given that the timestamps you can collect will most likely not correspond at all to what really happened on the display, and that you may use these timestamps to schedule presentation of future stimulus images, the whole system can get in some kind of complex feedback cycle where what you want and what gets reported to you as stimulus onset time is more than 1 frame off from reality, even with triple-buffering. Modern graphics drivers also judge gpu load by how many frames are pending in a wait queue, or how often vblank “deadlines” were missed, to speed up or slow down the gpu (as a power-saving measure), change the n-buffering strategy and various other stuff.
In practice i’ve seen errors of up to 3 video frame duration, e.g., 50 msecs at a standard 60 Hz refresh cycle.
There’s also multiple sources of triple buffering. E.g., on MS-Windows there is the DWM compositor as the typical culprit, but then the low level display driver itself may impose its own triple buffering on top of the triple buffering by the DWM. And user settings depending on gpu and driver. Another source of triple buffering on MS-Windows is most kinds of hybrid graphics setup with two graphics chips, e.g., NVidia Optimus laptops.
The DWM, like other compositors on other OS’es, can also decide to drop a frame from presentation completely if opportune to the system. Iow. a stimulus image is not ever shown, without you knowing it. These things can easily trip up attempts to validate timing with photo diodes and similar standard approaches. I found many ways to fool myself, or get fooled by the system doing something I didn’t expect, when using photo-diodes. Which is why I generally don’t trust statements of random people that they verified something with a photo-diode and it was fine. Depends a lot on the specific software and hardware setup, paradigm and exact stimulus script tested and analysis, if the photo-diodes tell the truth or if they just tell the truth one likes to hear.
On MS-Windows, with a properly configured system, a non-buggy graphics/display driver, properly written experiment software, and many other factors, one can get the DWM to switch to standby/bypass, and then only the low level display driver could introduce triple buffering again. Getting to this configuration depends on various rules that change over time, depending on OS version etc. The safest choice is a single-display setup with a standard DPI monitor.
On MS-Windows with Intel graphics, to my knowledge, triple buffering is applied by the Intel display driver in addition to potential DWM based buffering, and I don’t know of a way to disable that, after hours of searching the internet, forums, Intel user support forums, the Window registry etc. There may be some Intel chips that don’t do this in combination with some Intel driver versions on some Windows versions under some unknown conditions. Such unicorns have been spotted occasionally. But almost always when somebody reports using Windows with an Intel chip, it is the triple buffering causing trouble. The only machine with Intel chip that I have, running Windows 11, always triple buffers, and it is disruptive to my work - making timing tests on Windows 11 impossible for me and also annoying me with constant sync failures, so you can be sure I tried a lot to get rid of it for my own benefit, to no avail.
Psychtoolbox startup timing tests are designed - and failure thresholds chosen - to usually detect such DWM or triple-buffering interference indirectly by causing the sync tests to fail, e.g., because less than 50 valid flip samples can be collected within the test duration, or the “stddev” of the timing samples exceeds 0.2 msecs and other things I can’t remember right now. So a sync failure usually means a real failure, although an occasional sync failure, if it is the exception instead of the rule, could also mean that your system was just noisy or overloaded - false positives are unavoidable. If the welcome image with the frog wiggles during startup, you can be sure triple-buffering is active, specifically the one caused by the Intel display driver, so that is a strong visual indication that it is game over for you. There are more methods of diagnostics described in our help texts.
So all in all, if you wanted to have a constant one frame lag due to constantly active triple-buffering, you’d probably need to write a script that always presents stimuli at a speed higher than the video refresh rate of your monitor, without any pause (e.g., between blocks of trials, between trials, waiting for some external trigger or subject response etc.) ever, for whatever reasons, carefully maintaining that steady state against all the things that can cause timing variations on a Windows machine. And photo diodes to verify at all times this is the case, fool-proofed against all the ways one can fool oneself with such a setup.
The basic underlying problem with software-based visual stimulus presentation timing is that no operating system, apart from Linux in certain configurations, does have well working programming interfaces for visual timing and time-stamping and such, where the application just can tell the operating system what it wants timing-wise and the OS can report back timestamps of real stimulus onset with reliability and accuracy.
On Windows and macOS we always depend on all kinds of hacks and tricks to get timing working ok enough, and we have to make assumptions about how the underlying software and hardware work for these tricks to work. Those assumptions used to be fine in the olden days, but much less so since at least around the year 2010. These assumptions are sometimes broken and then things go sideways. E.g., whenever a desktop compositor kicks in for whatever reason. Or triple-buffering or n-buffering of any kind. Psychtoolbox is most advanced when it comes to tricks and diagnostics, compared to all other alternatives I am aware of, but there is still plenty of ways to break it. At least most of the time our diagnostics is capable of reporting the problems, e.g., in form of the dreaded sync failures, before harm is done.
On properly configured Linux/X11 with open-source graphics/display drivers, ie. generally on graphics hardware other than NVidia, we have reliable api’s to tell the OS when we want something to show up on the screen, and to get reports back iff it was shown and iff it was shown in a reliable way and when exactly the stimulus image left the video output of your graphics card. Triple-buffering or 4-buffering or 5-buffering or such doesn’t matter. Even on Linux+NVidia we at least have some more robust ways of detecting trouble if it happens, although abilities to fix or avoid trouble are way more limited.
That’s why the recommendation is given to switch to Linux if one wants to use Intel graphics in a safe way.