Calling win.flip() at every frame when using static stimuli: pros and cons

Hi Mat,

If crafting your own experiments in code, then yes, that can be an excellent technique to increase the precision of RT measurement. But Builder is general purpose software and can’t be that flexible. For example, what if the stimuli you create appear to be static in terms of what gets entered in Builder stimulus component dialogs, but you animate them in a code component?

This is actually a common technique, but there is no way that Builder could know about it. Breaking the refresh loop would also lock out code components from running code on every frame to do non display-related activities (e.g. periodic interfacing with external hardware).

Builder might evolve in the future to take advantage of new screen update techniques (e.g. Sub-ms precision and flexible frame durations with G-Sync), but for the time being, people wanting to break out of the screen refresh loop need to get their hands dirty with writing their own code, which it certainly seems you’re capable of doing.

Cheers

PS Please surround python code with backticks