Recording freezes when OpenGL application is in full screen mode

[egeexyz]

Note: This is NOT happening with OpenGL mode. It happens when the entire screen is captured.

It seems that when an application that uses OpenGL is in full screen mode, SSR freezes the recording until either the application ends or is no longer in full screen mode. I have tested this with Wine applications run through steam, Super Tux Kart, and Extreme Tux Racer. It is simple to reproduce:

1. Begin recording using "Record the entire screen" mode using any file format
2. Launch an application in full screen that uses OpenGL
3. Close the application
4. Stop recording
5. View recording

It seems like perhaps I am missing a dependency of some sort. Or perhaps display driver issues? I am using AMD binary drivers.

[MaartenBaert]

This happens with some combinations of drivers and window managers. Which window manager are you using?

Some window managers (e.g. the XFCE one) have an option to disable fullscreen unredirection (the source of this problem). It happens because some drivers continue to capture the window manager even when a game is displaying things to the screen directly (without going through the window manager).

[egeexyz]

Sorry, I should have mentioned my setup in the bug description.

I am using Ubuntu GNOME so Mutter (I think). I'm not aware of any way to configure Mutter aside from gconf. Are there settings in there I should tinker with?

[MaartenBaert]

I found this:

http://askubuntu.com/questions/99228/does-unredirect-fullscreen-windows-option-in-compiz-improve-performance-for-vi

I never tried it though. Mutter seems to be a bit problematic for SSR (particularly the overview/menu screen) and I have no idea why.

[egeexyz]

The information I've found suggests that Mutter has (had?) an issue with fullscreen unredirection. The problem is that there doesn't appear to be any real configuration with Mutter. The settings I've found in dconf didn't seem to have any affect on anything.

How sure are you that this is a problem with fullscreen unredirection? I ask because while my OS base is Ubuntu GNOME, I have both Gnome fallback/Metacity and Unity and both are having the exact same problem.

[MaartenBaert]

Metacity and Mutter share a lot of code. If Mutter is affected, then Metacity is probably also affected (at least if you have enabled compositing). Unity (i.e. compiz) also has this problem, but they have an option to disable it in CompizConfig Settings Manager.

You could try using Openbox, just for testing. It doesn't use compositing so it should be unaffected. If even Openbox is affected, then it must be a driver issue.

[egeexyz]

Ok, I will try Openbox later tonight.

However last night I tried running SSR on an Ubuntu 14.04 live CD and it recorded SuperTuxKart perfectly. However on my local machine recording using Unity doesn't work at all. Is it possible that there is some kind of configuration that is being passed from window manager to window manager? Also, at one point I had Oibaf's "optimized" graphics drivers installed, though I have recently purged them. Could those drivers be causing issues? - https://launchpad.net/~oibaf/+archive/graphics-drivers/

[MaartenBaert]

Possibly. You should try SSR with and without those drivers (while keeping everything else the same) to know for sure.

[egeexyz]

I tested SSR on an Ubuntu Gnome live CD and it recorded just fine. I finally ended up just wiping my hard drive and starting from scratch with Ubuntu 14.04. I believe one of two things happened that caused this issue:

1. I was using the pre-release update branch with Ubuntu. It's possible that an update changed something that caused this issue.
2. I was using "Optimized Graphics Drivers" with the AMD binary drivers. Its possible that the combination of the two caused this issue.

Ultimately, I was unable to find the root cause of this potential bug. It's likely that it was a combination of things, mostly configuration and or driver updates. It seems unlikely that it is an SSR specific thing but, I did not test any other screen recorders.

[egeexyz]

I managed to reproduce this issue by installing Ubuntu 14.04 GNOME on a clean environment and updating the system using the pre-release updates. I am still not sure exactly what is causing the issue, though it seems to be consistent.

I did find a logical workaround, especially for OpenGL games. Simply use the "Record OpenGL" setting.

I'm going to close this issue based on the fact that it is still an unconfirmed issue (I don't want to spend any more time on it) and that there is a simple workaround.

[egeexyz]

Reopening this issue because I garnered new data on this issue.

I got the latest SSR 0.3.0 and wanted to test it against the latest fglrx drivers. I first tested it against Ubuntu 14.x with Compiz/Unity. The result was the same: the video was capturing everything under the application, including the mouse cursor. Curiously, if the mouse cursor actually changed (XCOM on Steam does this), the video will record the new mouse cursor, but not any of the game footage.

I recently installed Xubuntu on a server and wanted to try SSR with fglrx drivers on it. The result is confusing but perhaps it can help explain what is happening.

When "Enable display compositing" is DISABLED in the "Window Manger Tweaks", the resulting video is identical to Ubuntu; everything 'under' the application is captured but not the application itself.

When "Enable display compositing" is ENABLED in the "Window Manger Tweaks", the resulting video is the actual game play footage; the defect is gone.

I briefly tested this using LXDE and Openbox and I was surprised to discover that the resulting video is the same as on Ubuntu; everything 'under' the application is captured but not the application itself.

I think we've established that the fglrx driver is doing something funky and causing screen capture programs to behave strangely. But why is the xfce compositor allowing it to capture application footage?

[MaartenBaert]

Everything changes when you enable compositing. The driver no longer knows where the windows are (because the compositor can transform them) so it can no longer do these optimizations directly. Instead it is up to the window manager to do the same (fullscreen unredirection). Apparently the window manager does it slightly differently and doesn't trigger the problem.

[egeexyz]

I've tested the latest fglrx drivers (14.6 beta) with Minecraft fullscreen against the window managers listed below. The results were interesting:

Compiz/Unity - Everything "under" the full screen application was captured. This included the SimpleScreenRecorder "information" section incrementing values. With Unity active, there doesn't appear to be a safe way to turn off compositing or OpenGL acceleration.

Gnome/Mutter - The entire screen freezes at the frame directly before the application going full screen. The "information" section is in SSR is frozen, unlike with Compiz and Unity. As far as I know, there are no settings for Mutter to turn compositing either on or off.

Openbox/LXDE - Same results as Gnome/Mutter.

KDE/KWin - The screen capture runs flawlessly. So apparently lag or other issues when recording "entire screen".

XCFE/XFWM - With compositing enabled, screen capture runs as expected. With compositing disabled, results are the same as Compiz/Unity. It should be noted that while with compositing enabled the screen capture works as expected, there is a noticeable amount of lag during gameplay and in the recording. KWin does not appear to suffer from this.