Window.flip() slower than expected on ubuntu

Coding
,
1

Hi all,

I am doing some real-time experiments that need low latency between each loop, and as high a frame rate as possible. On my office computer, this framerate is 60 Hz (16.7 milliseconds between frames). When I use IPython to check how long the Window.flip() function takes, however, I get double that (33.3 msecs). This makes me think that Psychopy is trying to do too much in the Window.flip() function, causing it to miss the next frame and have to wait until the next one.

Here is the code I used to test:

from pyschopy.visual import Window
win = Window()
%timeit win.flip()
>>> 10 loops, best of 3: 33.1 ms per loop

This doesn’t occur when I use Pyglet, though:

import pyglet
win = pyglet.window.Window()
%timeit win.flip()
>>> 100 loops, best of 3: 16.7 ms per loop

Here is some information on my setup:

  • Ubuntu 14.04 64-bit
  • 3 Monitors
  • Python 2.7.6
  • Psychopy 1.82.01
  • Pyglet 1.2.4

Is there something I’m doing that is slowing down Psychopy, or is this a bug?

2 Likes
2

See other discussions of this:
https://groups.google.com/forum/#!topic/psychopy-users/7RoZoJBLfdQ
https://github.com/psychopy/psychopy/issues/1139

It isn’t to do with things being too slow as such. This is a specific interaction with some linux systems and psychopy’s waitBlanking setting. We haven’t worked out exactly what systems show the problem so struggling to know how to get rid of it properly.

PsychoPy’s waitBlanking system forces OpenGL to wait until the physical screen refresh before continuing the script but what (I think) is happening is that some part of your ubuntu system is doing the same. Because both systems are waiting for a physical screen refresh we end up getting a double frame for each frame. Make sense? The easy workaround is to turn off waitBlanking in your visual.Window and let the system do it in your case.

The question is where this extra delay is occurring. Graphics card driver? Window compositor? I upgraded my 14.04 ubuntu to 16.04 and I don’t have the issue nay more, but I’ve also changed my graphics card drivers many times so I no longer know what fixed it.

If you are planning to update ubuntu to 16.04 I’d like to know what happens when you do.

Alternatively, Dan fixed it on his nVidia card by turning off vsync in his nvidia driver settings (using the proprietary driver not the open-source Nouveau driver).

I’m keen to know what happens on your system so we can work out how to detect/fix this, but there are several workarounds if you just need to get up and running.

best wishes
Jon

2 Likes
3

Thank you for the response!

Both the waitBlanking and the NVidia vsync solution worked for me. I also thought it was interesting that using both of them at the same time (no vsync in NVidia driver and waitBlanking=False) still resulted in a 16.7 msec flip time–I would have expected it to just flip immediately.

Code with the waitBlanking=False solution:

from psychopy import visual
win = visual.Window(waitBlanking=False)
%timeit win.flip()
>>> 100 loops, best of 3: 16.6 ms per loop

Best wishes,

Nick

4

One heads up, some people are reporting that the no vsync setting is not persistent across boots (I didn’t have this problem, though).

5

If you do ever upgrade to 16.04 would you mind checking first if your system is still doing the double-frame delay, then do the upgrade. I’d really like to work out whether the ubuntu system/drivers has fixed this in 16.04

thanks

6

I did a clean install of Ubuntu 16.04 and had this problem with the nvidia binary driver (priorietary). And this solution fixed it. I’ve not encountered any situation where it negatively affected some other program.

7

@lindeloev just to be clear, are you saying the the clean install of 16.04 fixed the problem, or that the clean install still had the problem and you fixed it by turning off waitBlanking in Window?

8

@jon, the latter: I got a new laptop, installed Ubuntu 16.04, saw the double-frame problem and both fixes worked individually. I went with the solution of disabling vsync in the nvidia driver since the waitBlanking solution would fail to work when collaborators run the script.

I’m happy to do any testing if you think there’s a python-side solution to this!

9

Since I know you were interested in hearing about this @jon , I updated my machine to 16.04, am now using the non-proprietary driver, and do not experience this problem anymore. Unless I’m mistaken, everyone who has complained of this was using Nvidia cards, and all who have specified the driver have been using the proprietary driver. So I would wager the issue is restricted to Nvidia card + Nvidia proprietary drivers.

1 Like