openframeworks / openFrameworks

openFrameworks is a community-developed cross platform toolkit for creative coding in C++.
http://openframeworks.cc
Other
9.93k stars 2.55k forks source link

Fullscreen framerate drop on linux 64 #5009

Closed frauzufall closed 8 years ago

frauzufall commented 8 years ago

Hey,

the framerate of any program drops down to 4 fps when going into fullscreen mode on linux 64bit. I tried the graphics/colorExample and an empty application with nothing but a background drawing.

I tried this main.cpp

int main(){

    ofGLFWWindowSettings settings;
    settings.multiMonitorFullScreen = true;
    settings.windowMode = OF_FULLSCREEN;
    auto window = ofCreateWindow(settings);

    ofRunApp(window, std::make_shared<ofApp>());

    ofRunMainLoop();

}

as well as the following with calling ofToggleFullscreen() on key press.

int main(){

    ofSetupOpenGL(1024, 768, OF_WINDOW); 

    ofRunApp(new ofApp());

}

I saw different issues related to fullscreen that seemed to be fixed but I found nothing about framerates. Any ideas?

arturoc commented 8 years ago

tis that with vertical sync enabled or without? if it's without and depending on the hardware even with it enabled it's perfectly normal, it's just the fill rate limit of the hardware.

try using OF_GAME_MODE instead of OF_FULLSCREEN which might be faster in certain cases.

there's also some settings in compiz (if you are on ubuntu) that might help. on the compiz config settings manager (doesn't come installed by default) in the composite section. disable unredirect fullscreen windows

you can also try if glxgears has the same effect, run glxgears to get the fps in a window and then glxgears -fullscreen

frauzufall commented 8 years ago

Thank you for your reply! The differences appear way too high to me.

OF_FULLSCREEN: ~3 FPS
OF_WINDOW: ~2100 FPS
OF_GAME_MODE: ~2100 FPS

(vertical sync on/off changes are minimal)

glxgears: ~12000 FPS
glxgears -fullscreen: ~3900 FPS

I used fullscreen before a while ago without noticeable problems. I run Xubuntu 15.10, no Compiz. Possibly still system related if I'm the only one with that problem, just wanted to ask. It bugs me because I need multiple monitor fullscreen and OF_GAME_MODE is not doing that. (Btw. there are also only minimal changes in FPS when unplugging the second screen) We can close this if no one else is affected.

PetrosKataras commented 8 years ago

Hey, just my two cents after pain and multi monitor setups on Linux. Try openbox ( probably @arturo would also suggest this :) ) as your window manager. Use devilspie2 for forcing window configurations and check your driver for this fps issue. If you have installed a driver on your own try to reinstall it ( or a different one ) since it sounds like a weird glitch that could be coming from there.

arturoc commented 8 years ago

yes this looks like a problem with the window manager. most window managers use openGL to do effects like windows minimizing... when you use an application that also uses openGL they usually make that application render into an fbo and then render that fbo into the screen. depending how that's done it can be slow.

OF's game mode is actually the real fullscreen, what we call fullscreen is just a window without decorations and the size of the current resolution of the monitor.

can you try with a different window manager? as @PetrosKataras suggests openbox is a good alternative for installations... since it doesn't use openGL itself so it's usually faster and also solves some problems with vertical sync and others.

another thing to try would be a more recent version of GLFW (we haven't updated in a while) but if glxgears has the same problem i'd say is just a bad implementation in the window manager

frauzufall commented 8 years ago

Hey, thank you for your replies!

I tested openbox with the same result. I was also not totally convinced about the window manager theory because glxgears works fine in fullscreen (see the framerates in the last post, it's slower, but 3900 FPS with glxgears -fullscreen is smooth and 3 FPS with OF_FULLSCREEN is not)

Another thing I recognized: It's running perfectly in fullscreen mode until I move the cursor. So I activate fullscreen via keyboard, animations run smoothly, move the mouse, framerate drops immediately.

I will try devilspie2 as well, thanks for the suggestion, just wanted you to know about the strange mouse event correlation.

arturoc commented 8 years ago

yeah that's strange. still the difference between 12000 and 3900 when running glxgears is really big but it could be because of the size of the window.

what fps do you get with vsync enabled? also what video card do you have? what fps do you get with an empty application? also the fact that only happens after moving the mouse is really strange too. it might be some problem with the version of glfw we are using (haven't been updated in a while) or something related with how we go to fullscreen.

something else to try is creating the window in window mode but without decorations and setting it's position to 0,0 and it's size to the size of the full screen. that won't cover the desktop bar but if you use something like openbox it would work as a workaround

frauzufall commented 8 years ago

I don't find a working solution. With vsync, the same happens. I was not exactly accurate before: Going into fullscreen gives me ~3FPS (with or without vsync), if I move the mouse, it freezes completely and I have to force quit.

devilspie2 is nice but I can't get the window to span over 2 displays. How did you manage to do that, @PetrosKataras? I can set it to fullscreen or hide the window decoration, but even setting the size to the sum of both displays results in the window only shown on one screen. Same with openbox and xfce.

I also tried updating glfw using the apothecary formula. I had to copy some files from apothecary/build/glfw to apothecary/build/_buildroot in order for it to finish successfully. I got undefined references when trying to compile OF afterwards so I changed the source for glfw from @arturoc s to the glfw github repository in the formula, had to comment out glfwSetKeyCallback and glfwSetDropCallback in ofAppGLFWWindow to get it running but the fps dropdown / freeze happens as well.

Thank you for the patience!

frauzufall commented 8 years ago

Tests are done with an empty application, my video card is a GeForce GTX 970M. I will also try the same with an older laptop I own.

arturoc commented 8 years ago

do you have the propietary nvidia drivers installed?

frauzufall commented 8 years ago

Yes, nvidia-352. I think that's the first version to support my hardware. I tried my old laptop and everything's fine there. This is probably not OF related and we can close this, I am thankful for any other tips though.

arturoc commented 8 years ago

we actually use specific code to change to fullscreen in OF since glfw doesn't directly support it so there might be something in there that it's causing this.

can you try commenting out this lines in ofAppGLFWWindow.cpp 703-707:

        // tell the window manager to bypass composition for this window in fullscreen for speed
    // it'll probably help solving vsync issues
    Atom m_bypass_compositor = XInternAtom(display, "_NET_WM_BYPASS_COMPOSITOR", False);
    unsigned long value = fullscreen ? 1 : 0;
    XChangeProperty(display, nativeWin, m_bypass_compositor, XA_CARDINAL, 32, PropModeReplace, (unsigned char*)&value, 1);

everything else is pretty standard so if that doesn't fix it it's probably just some problem with your card and fullscreen mode in x.

another thing to try would be to use ofAppGlutWindow instead of GLFW and see if that solves it and also test the glfw examples but i think those won't let you change to fullscreen spanning several screens

frauzufall commented 8 years ago

No changes with commenting out these lines. I managed to find the lines that cause the slowdown. The problem is calling glfwGetMonitorPos() und glfwGetVideoMode() from getScreenSize().

https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppGLFWWindow.cpp#L503-L504 https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppGLFWWindow.cpp#L477

I also have general problems with positioning external displays with e.g. arandr (crash, logout) This may be related.

In ofAppGlutWindow it is working! I thought I was not able to do multiple monitor fullscreen there but it worked in OF_GAME_MODE with the right window size parameters - awesome! Is there a way to use normal multiple display fullscreen mode with ofAppGlutWindow (where I can switch windows)? There is no such option in ofGLWindowSettings. Otherwise I will use game mode.

macpete commented 8 years ago

I'm affected by the same problem, with exactly the same symptoms. My system has two monitors attached to a GTX670, using the proprietary NVIDIA driver 316.28 on Ubuntu Gnome 15.10.

Upon slowdown one CPU core is pegged in kernel mode in the NVIDIA driver (_nv014095rm) by way of the X server, rendering the whole system nearly unresponsive.

The slowdown happens with 0.9.3, but not with 0.9.2.

The first bad commit is:

commit a39e8ad8964378a53996c9fe696d40497fb62694 Author: arturo castro arturo@openframeworks.cc Date: Tue Mar 8 12:25:04 2016 +0100

ofAppGLFWWindow: fix w/h on setup when on fullscreen
arturoc commented 8 years ago

can you check if https://github.com/openframeworks/openFrameworks/pull/5028 fixes it?

macpete commented 8 years ago

5028 indeed fixes the slowness for me. Thanks!

frauzufall commented 8 years ago

Yes, that fixes it for me as well! Thank you!

mruegenberg commented 7 years ago

I have this issue with oF 0.9.8 on Arch Linux, KDE proprietary NVIDIA drivers, GTX 680. The symptoms are exactly the same as for frauzufall, down to the slowdown only occuring after moving the mouse. OF_GAME_MODE works, but I need multi-monitor support.

I'm assuming the above fix is included in oF 0.9.8, so this seems like a regression. It also occurs with oF 0.9.3. Are there maybe some hints on where to start looking for the origin of this bug?

arturoc commented 7 years ago

i think this was fixed in master but not in the 0.9.x branch, can you test if the niightly builds have the same behaviour?

mruegenberg commented 7 years ago

Yes, it works in the nightly as expected.

oF 0.9.8 also works by applying the commit fixing it as a patch: patch -p1 < 0001-several-fixes-for-glfw-and-main-loop.patch (I needed to re-run compileOF.sh and also re-compile poco via archlinux/install_dependencies.sh afterwards.)

Thanks for the quick response :-)