Short scenes and idle(...) calls can be skipped on some displays

Hello,

Thanks again for all the work you've put in on the package - you may want to know about an oddity we ran across recently (and found a good workaround for).

Our protocol ends in a wait period, and we discovered that idle(...) still allowed the last scene's objects to reappear on screen, so I added a blank scene with only a time counter in it, and noticed that under certain circumstances, we still ended up seeing stimuli from the previous scene on the subject screen, but not on the control screen. And: this only occurred when two displays were connected and in use, not when the subject and control screens were on the same display.

After some testing, and ruling out hardware causes, we discovered that it only occurred when the final (blank) scene and the idle call were both less than a full frame's duration. It would appear as though, while the control screen treats them as though they've occurred and therefore ends with a blank display, the subject screen skips them (since they're less than a frame) and ends with the previous scene containing the stimuli, which also means it's showing different content than the control screen.

Either way, the fix was relatively simple - just ensure that the blank scene is ceil(1000.0 / MLConfig.Screen.RefreshRate) milliseconds long, and use an idle after that with a similar time.

Thank you for reporting this. I have a different idea about the cause, though. The adapters are not designed to skip a scene of which length is less than a frame. And what happens at the end of a trial is a little difficult to tell because that is the time when the subject and control screens are programmed to display different things. I do not have time to look into this at the moment, but I will email you later to get some information that I need.

In the meantime, maybe you can try this. Was your subject screen the main display of the system when you ran the test? If not, can you run the test again after making the subject screen the main display?
https://monkeylogic.nimh.nih.gov/docs_MonitorSetup.html

I can rerun the test next time I'm on-site, for sure! Let you know what I find out. That explanation makes a lot of sense, though; I'd figured it was something like that - after all, each display has its own VSync to worry about.

For now, the workaround we came up with last week seems to be functioning, so I don't have a pressing need for a solution, which is nice, but I'll see what I can do to get you the information you might be able to use.