Occasionally you will drop frames if you
Things to avoid:
stim.setOri(ori), stim.setPos([x,y]...)
For OS X users there are some further tips on reducing dropped frames here
The key sometimes is knowing if you are dropping frames. PsychoPy can help with that by keeping track of frame durations.
By default, frame time tracking is turned off because many people don't need it but can be turned on any time after Window creation using
Since there are often dropped frames at the beginning of a run, it makes sense to start off with a fixation period, or a ready message and don't start recording frame times until that has ended. Obviously if you aren't refreshing the window at some point (e.g. waiting for a key press with an unchanging screen) then you should turn off the recording of frame times.
The simplest way to check if a frame has been dropped is to get PsychoPy to report a warning if it thinks a frame was dropped:
The above code will spit a warning message only if the the current frame AND the average of current and the previous frames exceed self._refreshThreshold value (often a long frame is making up for an 'apparently' brief previous frame - see below).
While recording frame times, these are simply appended, every frame to win.frameIntervals (a list). You can simply plot these at the end of your script using pylab:
Or you could save them to disk. A convenience function is provided for this:
The above will save the currently stored frame intervals (using the default filename, 'lastFrameIntervals.log') and then clears the data. The saved file is a simple text file.
You should see that most of your frame times are sitting roughly at the frame period for you monitor (with very little variability). At times you might see that frames are suddenly high, and these are most likely dropped frames. However, you might also be seeing bi-directional spikes where a very short frame is followed by a long one, with their average being the same as the nominal frame rate. I (jon) believe, based on reports from Andrew Straw (2008) that this is caused by the fact that the graphics card will 'block' (wait for the frame to end before returning to the script) only if a frame is already waiting to pass through the pipeline. So, when your graphics card is easily keeping up with drawing you see no spikes at all (it always has a spare frame queued-up so always 'blocks'. When the graphics card is just keeping up it doesn't always have the back-up frame ready, so doesn't block and the result is that the frame looks very brief (it was actually displayed at the same time), but is then followed by one that looks very long. I don't think these are a problem for most experiments - when they occur during the presentation of moving dots you don't see the characteristic judder of a dropped frame. When the drawing is falling so far behind that it fails to draw within the frame you get the simple skip of a frame, which you see as a single long frame, without the short one. This IS a problem in most experiments.
for further info see:
