Attempting to measure frame rate of screen ... before each trial

I am having “attempting to measure frame rate of screen, please wait” presented shortly before each trial. Cannot kill it. Here in my office I use the latest version of the psychopy package (2026.1.2. on a windows 11 system). In the lab I have the same issue on a different machine, also windows, proably somewhat older version of psychopy. In the lab I start the script from the prompt.

I scrolled through the topics here and found checkTiming=False. Well I am using in the script I am currently testing both in my office and in the lab:

win = visual.Window(size=(SCREENSIZE), fullscr=False, checkTiming=False, units=‘pix’, color=‘grey’)

Any suggestions?

How often are you creating the window?

I am creating the window one time near the beginning of the script. I thought it might have something to do with the fact that the system is managed by the IT department and that psychopy tries to save data somewhere where it is has no rights?

Does it still do it if you make a simple experiment in Builder (one loop around one routine)?

I assume you are using Coder.

thanks a lot, wakecarter.

I identified the problem. I included

          win.getActualFrameRate()

in a routine that sends data to the eye tracker on each trial. the routine is one that I defined years ago and used it since then in some of the scripts. The problem apparently appeared when PsychoPy began to issue the message in one a version change.

Evidently it was me being lazy to program it in this way instead of checking the frame rate at the beginning of the experiment once; that said, I am probably not the first user of psychopy who does not wish this behavior. I do not think that the frame rate test should be announced to the participant when it is done in the inter trial interval.

Hello @gernot

For testing purposes, I checked the frame rate in an experiment before each trial. I never got the message that the frame rate is being tested. Notice that the frame rate test at the begin of the experiment lasts about 60 sec AFAIK and then reports an average frame rate. I did my frame rate test in PsychoPy 2025.2.4 in a code-component in the Builder.

Best wishes Jens

Could you measure the frame rate in the ITI by saving the value of frameN at the end of the ITI (if it has a fixed duration in seconds) or saving the value of t (if it has a fixed duration in frames)?

Hi Jens, good to know.

Hi wakecarter, thanks for the suggestion. This should be possible. In many contexts of my experiments, however, the exact length of the ITI is not of concern. the getActualFrameRate is used to save the framerate to the results file, just to be sure and for later reference.

(and please (!) devolopers of psychopy, consider repairing this: I expect from a routine that says “get the actual frame rate” definititly not that it prints something on the screen)

If you know the length of the ITI in both frames and time then you have an estimate of the frame rate.

I may be wrong, but I don’t think that the developers have anything to fix because I don’t think that the intended purpose of getActualFrameRate is the purpose you are trying to use it for.

Hello @gernot

I am on the same page as @wakecarter. The command

refreshRate = round(win.getActualFrameRate(), 2)

never printed anything on the screen when I used it. There must be another reason for the behaviour you observed. Finding out why is important in itself.

Best wishes Jens

The relevant change was made in 2023.2 (“Window now explains it is performing timing test by @mdcutone in #5511”).

When getActualFrameRate is called, it gets the frame rate by presenting a number of frames and measuring the time they take. This means delaying your experiment while the test runs, which could have all sorts of knock on effects if you’re using custom code to control timing. We added a message to make it extremely hard to miss that this is happening.

The frames will be presented either way; this is an unavoidable consequence of how the test works. But if you don’t want the message, you can mute it by calling getActualFrameRate with infoMsg="".

Thank you all!

Your answers helped me to identify and understand the problem. Central is that I misunderstood the nature of getActualFrameRate. I guess it is a common misunderstanding and someone thought “Hey, people may not get that this lasts some 100 ms, so let’s alert them”.