Psychopy: Framerate in Ubuntu twice as slow as system frame rate

[dantheman39]

Hi everybody! I noticed this problem on two of my machines and it was driving me crazy: my monitor has a refresh rate of 60hz but the experiment is being run at 30hz. Thankfully Jon @peircej and Sebastian had already found a solution to this for Ubuntu a while back:

https://groups.google.com/forum/#!topic/psychopy-users/7RoZoJBLfdQ

The solution was to set the waitBlanking=False on the window, which solved my problem and I'm very happy about that. But a transparent fix doesn't seem to have made it to the code. I'm thinking there could maybe be a couple of lines added in psychopy/psychopy/visual/window.py to make waitBlanking=False the default option on Linux? It seems to be a pretty important issue, since all of my display times would be twice as long as I expected if I hadn't caught this! All of the details with monitors, frame rates and refresh rates are well out of my depth at this point, so you guys would best know how to proceed, but if there's any way I can help please let me know (I didn't include a ton of info here since Jon seems to understand the issue. If you would like more specifics I will definitely add more).

I'm genuinely enjoying the software so far, and am very thankful for your making and maintaining it. Hope you are all doing well.

[peircej]

I agree. The question is knowing whether this is universal and whether it can be turned on/off in the system. I haven't been certain about where the ubuntu result comes from and therefore whether it's safe to turn off waitBlanking in all linux systems. On my office computer (14.04) using Gallium AMD video driver I don't have the frame-halving problem.

We could check the results of the initial window call to get the actual frame rate (if rate<40Hz then turn off waitBlanking). That wouldn't catch issues with a 120Hz monitor actually running at 60Hz.

Better, maybe we can test what the expected refresh was using xrandr and compare that with the measured refresh?

Ideally though, we'd work out what in the ubuntu system (window compositor?) was doing the sync step. I've just seen that pyglet has a setting for xsync. I'm not sure what that is but could you try doing

import pyglet
pyglet.options['xsync'] = False

at the top of the timing script with waitBlanking=True and see if the effect goes away?

[peircej]

PS, note that I'm peircej not piercej ;-)

[dantheman39]

My bad with the misspelling. I tested the script with your code setting pyglet's 'xsync' option to False and leaving windowBlanking at True, but it still halves the framerate. For the record, I'm on Ubuntu (unity) 14.04 on both computers, with an nVidia 650m in the laptop and GTX 960 in the desktop.

Also, here's my output for a call to xrandr:

VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
1920x1080 60.0*+
HDMI-0 disconnected (normal left inverted right x axis y axis)

[dantheman39]

Ah! I found something, (though sorry I still don't quite understand what's going on). I was poking around in the NVIDIA X Server Settings application that controls the graphics card, and saw an option for "Sync to VBlank" was checked. I unchecked it and the problem was solved. Hopefully this helps elucidate the problem?

[peircej]

Well, your finding supports my belief that the problem is with PsychoPy and the graphics driver both trying to perform a sync and the result being a double wait.

But it also emphasises that on linux the problem is tricky because the behaviour varies from one computer/graphics card to another. In general we want that sync setting turned on and we want psychopy to handle either situation seamlessly, which means detecting whether or not it should wait for another blank period.

Maybe the code in Window.flip() should (for linux only) test the current time and guess whether we should wait or whether the system has inserted a wait already.

[dantheman39]

it also emphasises that on linux the problem is tricky because the behaviour varies from one computer/graphics card to another

I completely empathize. I wish I knew more about the topic and could suggest a good solution. At least we're more sure that it's probably related to the graphics card, and seems to specifically be related to nVidia cards and/or drivers. Note that Sebastian from the linked post above also was using an nVidia card with their proprietary driver. Please let me know if there's anything else I can provide.

[piercej]

please drop me from this thread, I've got nothing to do with this and
can only thing my email somehow got picked up by mistake as my name is
somewhat similar.

On 3/16/2016 5:53 AM, Jon Peirce wrote:

I agree. The question is knowing whether this is universal and whether
it can be turned on/off in the system. I haven't been certain about
where the ubuntu result comes from and therefore whether it's safe to
turn off waitBlanking in all linux systems. On my office computer
(14.04) using Gallium AMD video driver I don't have the frame-halving
problem.

We could check the results of the initial window call to get the
actual frame rate (if rate<40Hz then turn off waitBlanking). That
wouldn't catch issues with a 120Hz monitor actually running at 60Hz.

Better, maybe we can test what the expected refresh was using xrandr
and compare that with the measured refresh?

Ideally though, we'd work out what in the ubuntu system (window
compositor?) was doing the sync step. I've just seen that pyglet has a
setting for xsync. I'm not sure what that is but could you try doing

|import pyglet pyglet.options['xsync'] = False |

at the top of the timing script with waitBlanking=True and see if the
effect goes away?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/psychopy/psychopy/issues/1139#issuecomment-197308784

john r pierce, recycling bits in santa cruz

[peircej]

Sorry piercej, yes you were mentioned as a typo. We can't choose to drop you but you can unsubscribe by going to the web interface of this thread (linked in your email) and clicking the Notifications>unsubscribe button on the right.

[hoechenberger]

Apparently this can really be caused by the compositor:
https://forums.tigsource.com/index.php?PHPSESSID=47d8cb175777e99487777e07d909dfbe&topic=19884.msg568899#msg568899

https://steamcommunity.com/app/290770/discussions/0/45350244941380428/#c34094415767088132

Although some users experience this issue also when using a non-compositing desktop.

While one could use xlib directly to figure out whether a compositor is running, I discovered that Qt also offers this functionality -- might be easier to use! It's even accessible via PyQt.

But six months ago, it didn't work flawlessly from PyQt; one had to call the Qt C++ functions directly to get the correct result.

But maybe this is fixed by now?

[hoechenberger]

Just discovered python-xlib, this might be just what we need.

[kleinerm]

I don't know if PsychoPy does something additional or unusual wrt vsync, but as a first approximation:

One thing for you to go through would be "help SyncTrouble" from Psychtoolbox, linked here...

https://raw.githubusercontent.com/Psychtoolbox-3/Psychtoolbox-3/master/Psychtoolbox/PsychDocumentation/SyncTrouble.m

... for the checklist of things to check if PTB reports sync trouble, especially the Linux section.

The other is that on any existing operating system you can only get proper visual timing with a classic fullscreen window, aka fullscreen, top-level, unoccluded by anything else, decorationless etc. If you use windowed presentation i can virtually guarantee you that your timing will always be false or highly unreliable. Fullscreen means "covering the full X-Screen", e.g., on a multi-display setup, just covering a monitor is not sufficient if all displays are connected to the same X-Screen.

In principle all you'd need to do is to make OpenGL sync its bufferswaps to the retrace, and use that sync trick from PTB that Jon ported at some point a couple of years ago to PsychoPy.

The xsync command has btw. nothing to do with vsync etc. It makes the x-protocol synchronous, or if it refers to the xsync extension, solves some other graphics sync issues, not related to the display itself.

Compositors like the Compiz compositor of the standard Ubuntu 14.04 LTS Unity GUI switch themselves off if a fullscreen window is displaying, so they can't cause extra trouble, at least not for single display setups.