The screen frame rate can be 60 or 120 Hz depending on the device and the test properties. That means that a new image has to appear on the screen every 16.667 or 8.889 milliseconds. That time is the expected frame duration.

The calculations required to render a new image may take longer than the expected frame duration. In that case, the previous image will be on the screen for a longer time, until all the calculations are made and a new image can appear. We call the frames that last more than expected long frames.

Ideally, the number of long frames in your test should be zero. But because the number of calculations is higher during some frames (for example during the frame that appears just after a response) it is possible that the total number of long frames in your test is not exactly zero, although it should be a very small percentage of the total.

Every time you preview a test, a message is displayed informing you about the number of long frames.

Every time you run a test, a results report is created. There you get detailed information about which frames last longer than expected and their real duration in seconds.

If you get more than a few long frames, you need to reduce the computational cost of your test to get a more steady frame rate. Try to follow the next steps:

• Reduce the frame rate to 60 Hz if you are running your test at 120 Hz and having this high frame rate is not essential to your test.
• Minimize the numberOfLayers in your scenes because each extra layer adds additional computational cost.
• Disable the continuosResolution property of the scene.
• Reduce the number of stimuli present at the same time.
• Reduce the size of the stimuli.
• If you want an object to be present in some trials but not in others, make its activated property zero or one depending on the trial. When the activated property is zero, no CPU or GPU cycles are used to compute the object.

Image and audio synchronization

When the user specifies that the auditory and visual signals should be presented at the same, some small audiovisual delays occur. The average delay is around -10 to 10 ms depending on the device. It is possible to correct this average delay. 

You need to present several times an audiovisual signal specified to be presented at the same time and calculate the average delay measuring the signals with an oscilloscope. Then, you should include the average delay in the delayAudio60 or delayAudio120 variable of the app settings using a positive sign if you want that the correction delays the auditory signal presentation and a negative sign if you want that the correction delays the visual signal presentation. 

The variability of the delay across presentations (precision) is less than 1 millisecond (standard deviation) and cannot be corrected. 

Reaction times 

The images to be presented on the screen are delivered with a certain constant frame rate.

From the moment the images are delivered until they are displayed on the screen, there is a small delay of about 10-30 ms depending on the hardware. This delay is approximately constant for each session although variable across sessions.

All timers are synchronized with the delivery time of the images and the delay in the presentation of the images is stored in a variable named scene_delayDisplay in the results report.

When measuring reaction times, you may want to consider this delay. If you want to know the real duration that the image has been drawn on the screen at the time of the response, it is necessary to subtract the value of scene_delayDisplay from the value of scene_responseTime.

If you want to know the real duration of a scene, you can use the variable scene_duration, no need for any correction, as all the frames that are part of the scene are displayed with the same delay.

These are the relevant values you get in the results report:

• scene_duration: the real duration of the scene in seconds (one value for each scene in the section).

• scene_responseTime: the real time of the response, if there is one. Note that the duration of the scenes that require a response is usually one frame (16.666 or 8.888ms) longer than the scene_responseTime. This additional frame is used to stop any sound or video and prepare for rendering the next scene. When the scene does not require a response, its duration is known in advance, and these processes and calculations are performed in the last frame, so in that case, no additional frame is needed.

• scene_delayDisplay: the images to be presented on the screen are delivered with a certain constant frame rate. From the moment the images are delivered until they are displayed on the screen, there is a small delay of about 10-30 ms depending on the hardware. This delay is approximately constant for each session although variable across sessions. This variable measures that delay. Thus, if you want to know the real duration that the image has been drawn on the screen at the time of the response, it is necessary to subtract the value of scene_delayDisplay from the value of scene_responseTime.
  

When working with reaction times, you will need also to consider the sampling rate of the touch responses.

Touch information is sampled at 120 Hz in all devices, except for the iPad Pro 11-inch first generation (and later) and the iPad Pro 12.9-inch third generation (and later) in which the sampling rate is 240 Hz.