Synchronization failure due to use of deficient Intel graphics on MS-Windows

Hello everyone. Thank you very much for your help. I’m conducting research using Psychtoolbox in fMRI, and I’m facing synchronization issues with critical timing concerns. During the study, the code runs on a computer connected to another screen (where the participant sees the display inside the scanner) and a tablet. The problems I am encountering are as follows: I need the participant to see the cursor (to appear on the display screen so that the subject knows where they are touching the tablet and can draw). On some computers, the cursor is visible, but on others, when Psychtoolbox is opened in full-screen mode, the cursor cannot be seen.

Additionally, I have a synchronization problem. Moreover, on the computer where the cursor is visible, it is running Windows 11, which complicates matters.

However, my main concern is the synchronization issue. While I can work around this by increasing the threshold, timing is critical to my research, and I don’t want to compromise on that. Does anyone have any ideas that can help me? I would greatly appreciate any help and advice. Thanks, Keren

If ShowCursor() does not ensure the cursor is shown, then i guess a good way is to manually draw it (so a manually coded crosshair or image of a curcor or so) each frame in PTB. That would be reliable and should do the trick.

Regarding sync, we need more info (hardware, output for ptb), but windows 11 (or 10) and multiple displays is asking for trouble from what i understand. Is dual booting to linux or even replacing windows with Linux and option?

Thank you. Regarding the issue with the cursor, indeed ShowCursor() is not working. I will try the solution you suggested. Thank you. As for the synchronization problem, it seems that the issue is deeper than I initially thought (unfortunately). I am getting the synchronization comment even when running the code before connecting to other monitors. I am attaching the error message I receive. Any ideas? Will switching to Linux help?
TB-INFO: This is Psychtoolbox-3 for Microsoft Windows, under Matlab 64-Bit (Version 3.0.19 - Build date: Feb 20 2023).
PTB-INFO: OS support status: Windows 11 (Version 11.0) is not supported.
PTB-INFO: Type ‘PsychtoolboxVersion’ for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file ‘License.txt’ in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: For information about paid support, support memberships and other commercial services, please type
PTB-INFO: ‘PsychPaidSupportAndServices’.

PTB-INFO: The detected endline of the vertical blank interval is equal or lower than the startline. This indicates
PTB-INFO: that i couldn’t detect the duration of the vertical blank interval and won’t be able to correct timestamps
PTB-INFO: for it. This will introduce a very small and constant offset (typically << 1 msec). Read ‘help BeampositionQueries’
PTB-INFO: for how to correct this, should you really require that last few microseconds of precision.
PTB-INFO: Btw. this can also mean that your systems beamposition queries are slightly broken. It may help timing precision to
PTB-INFO: enable the beamposition workaround, as explained in ‘help ConserveVRAMSettings’, section ‘kPsychUseBeampositionQueryWorkaround’.

PTB-INFO: OpenGL-Renderer is Intel :: Intel(R) Iris(R) Xe Graphics :: 4.6.0 - Build
PTB-INFO: VBL startline = 1080 , VBL Endline = 1079
PTB-INFO: Measured monitor refresh interval from beamposition = 16.666153 ms [60.001849 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.662120 ms [60.016372 Hz]. (50 valid samples taken, stddev=0.239670 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
PTB-INFO: ==============================================================================================================================
PTB-INFO: WINDOWS DWM DESKTOP COMPOSITOR IS ACTIVE. On this Windows-10 or later system, Psychtoolbox can no longer reliably detect if
PTB-INFO: this will cause trouble for timing and integrity of visual stimuli or not. You might be just fine, or you could be in trouble.
PTB-INFO: Use external measurement equipment and independent procedures to verify reliability of timing if you care about proper timing.
PTB-INFO: ==============================================================================================================================

WARNING: Couldn’t compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?


One or more internal checks (see Warnings above) indicate that synchronization
of Psychtoolbox to the vertical retrace (VBL) is not working on your setup.

This will seriously impair proper stimulus presentation and stimulus presentation timing!
Please read ‘help SyncTrouble’ for information about how to solve or work-around the problem.
You can force Psychtoolbox to continue, despite the severe problems, by adding the command
Screen(‘Preference’, ‘SkipSyncTests’, 1); at the top of your script, if you really know what you are doing.
and the psychtoolbox version is -

'3.0.19 - Flavor: beta - Corresponds to SVN Revision 13790

The sync issue could be caused by triple-buffering. If it is, and if triple-buffering cannot be disabled, you might want to try this workaround (taking the naysayers’ warnings into consideration with a grain of salt).

Triple buffering on Intel + Windows is one of the common causes for timing failure on Windows. A builtin visual diagnostic indicator for that is if the welcome screen wiggles or vibrates. Ofc. there may be fMRI study paradigms where one can get away with up to ~50 msecs visual timing errors.

Switching to Linux would likely help with existing hardware. On MS-Windows, swapping your graphics card to something not Intel may help on single display setups, but multi-display on MS-Windows is usually fraught with additional problems, may or may not work reliably in your case. Reliable timing on multi-display (or in general) therefore makes Linux the better bet. I don’t get what you say about “tablet”? Anyhow, help PsychPaidSupportAndServices for any further advice.

Hi Mario, is it feasible for PTB to ever work on the new Macs with the Apple Silicon chips and the latest OS? If it were possible, what resources would you need to do it, and how long would it take?


Hi Keith. This question is somewhat off-topic for this thread. See Using toolbox with Big Sur and M1 MacBook? - #24 by mariokleiner for the best-fitting and most often read thread on this topic. The situation has evolved since my last post there. Repost questions there. But in principle, based on over 270 hours of research work on an Intel MacBookPro under macOS 10.15, 12.x, 13.x with AMD graphics, I’d say “Maybe” and “More research is needed”.

Oh sorry, I don’t know how my response got sent to that thread.

Anyway, I may have some funding for this. If interested in the possibility, please e-mail me directly.


Hey! I’m very new to psychtoolbox and I am having the same issue with windows + intel graphic card. I understand that this problem seems unsolvable as of now but I am not 100% sure I understand what the consequences exactly are. Is it possible to say how much timing error it can result in max? Is it that ~50 msec that you mentioned here? Or is it impossible to estimate the extent of the error?
As in another feed with a similar question you write: “Setting this value to, e.g., 0.5 msecs does not mean you are willing to accept 0.5 msecs timing errors during the experiment at all. It means that your are 100% confident (thanks to your very extensive low-level expert knowledge and measurements) that the, e.g., 0.4 msecs timing variability measured during self-tests and calibrations are not caused by any real visual timing problems, but are only system timing noise that can be safely ignored.” - Though this referred to manually changing the acceptable variance.

Thank you a lot for your answer!


In theory, the error could be unbounded, but in practice 1-3 video refresh cycles or ~16.6 msecs - ~50 msecs are the likely range, so if you don’t need better than 50 msecs accuracy, you could simply use the SkipSyncTests setting to keep going on Windows + Intel.

If you know by independent verification with suitable test hardware and setup that the observed noise is really just a system with very noisy timing, you could loosen the thresholds a tiny bit to make tests pass. But the current thresholds are set to likely fail the tests on broken systems, and likely pass the tests on properly working systems. And on MS-Windows in many cases PTB will loosen the threshold already to 5x the specified values to deal with the shoddy scheduling of Windows.

On Linux Intel graphics works perfectly in my experience, so that’s one way to salvage a machine with Intel graphics if one needs precise and trustworthy timing.