I'm currently getting a strange behavior from my GLFW based application, running under 64bit Windows 10 Enterprise (8 core 16 threads, 32GB, RTX2080) w/two external 4K monitors.
The application is a plain vanilla glfw loop (with some imgui), except that I place the window with glfwSetWindowMonitor(...) during startup right after calling glfwCreateWindow(...). This somehow halves the framerate (a little below 30fps) when the window is placed on the two external monitors' area. If I move the window just one pixel the frame rate quickly doubles to the monitors' framerate (60fps).
Is this something others have seen? Can I somehow shake the app out of its slumber?
Related
I am working on a graphical application that supports multiple operating systems and graphical back ends. The window is created with GLFW and the graphics API is chosen at runtime. When running the program on windows and using OpenGL, Vsync seems to be broken. The frame rate is locked at 60 fps, however, screen tearing artifacts appear. Following GLFW documentation, glfwSwapInterval(0); should unlock the frame rate from the default of using VSync. That works as expected. Using glfwSwapInterval(1); should lock the frame rate to match the monitors refresh rate. Not calling glfwSwapInterval(); at all should default to using VSync. While frame rate is correcly locked / unlocked using these calls, I experienced extremely interesting behaviours.
When glfwSwapInterval(); isn't called at all, VSync is set as default. But the wait for the next frame happens at the first draw call! One would think that the delay for the next frame would happen at glfwSwapBuffers(). No screen artifacts are visible what so ever.
When calling glfwSwapInterval(1);, Vsync is set and the delay for the next frame happens at glfwSwapBuffers()! That's great, however, when explicitly setting VSync, screen tearing artifacts appear.
Right now, not calling glfwSwapInterval() for using VSync seems to be a hacky solution, but :
The user wouldn't be able to disable VSync without window reconstruction,
The profiler identifies the first draw call taking way too long, as VSync wait time is somehow happening there.
I have tried fiddling with GPU driver settings and testing the code on multiple machines. The problem is persistent across machines if using windows and OpenGL.
If anyone can make any sense of this, please share, or if I am misunderstanding something, I would greatly appreciate some pointers in the right direction.
EDIT:
Some other detail: the tearing happens at a specific horizontal line. The rest of the frame seems to work properly.
After doing some more tests, it seems that everything is working as intended on integrated graphics. Correct me if I am wrong, but it looks like it is a graphics driver issue.
I have a full screen QT OpenGL application which needs to display the virtual keyboard (tabTip.exe) when input textboxes are entered. The problem I'm facing is that the virtual keyboard appears behind the application when the keyboard is invoked. I have tried many different things and found that the only way I can make it appear in front, is if my window is not fullscreen (e.g. making it 1 pixel less than full screen in the width and/or height). If I have the tablet in portrait mode this also still displays the keyboard even in full screen.
Now I'm trying to figure out if this is a driver issue, Qt issue, OpenGL issue or general windows issue.
Any suggestions?
Update:
I have investigated this a bit further and I think I see what's going on.
Windows 8, upon detecting that the monitor rotation is set to zero, and that it has an OpenGL window that matches the desktop resolution and covers the whole screen, kicks into legacy mode that blocks any Windows 8 themed animations from running (including virtual keyboard).
Do you have any suggestions on how I can stop windows from doing this? DwmEnableComposition has been removed in windows 8.
I want to develop one OpenGL application that is using the two monitors for display. However, if I specify the window size in glutInitWindowSize() to be the size which is the sum of the two monitors, then the result window is still always in one monitor, even though I can drag the window to another monitor or reshape.
Does OpenGL automatically detect another monitor and use the total size of the two monitors?
It's not OpenGL that is limiting the size of the window, it's GLUT.
You have to figure out a way to change the way GLUT sets up and creates a window. On Windows, it seems you can use win32 API to change these settings during runtime.
Here is the situation:
I have 4 SFML windows, which are inside a container which I have built. The container calls independent redraw methods for each window, starting with the first and ending with the last.
If each window's drawing code contains the lines drawMyCube() OR glClear(...), then the frame rate becomes slow.
drawMyCube() just draws a cube which rotates depending on the value of an sf::Clock object.
If one window calls (either of) these functions, the frame rate is ~60fps.
If two windows call (either of) these functions, the frame rate is ~30fps.
If three windows call (either of) these functions, the frame rate is ~20fps.
Finally, if all four call (either of) these functions, the frame rate is ~15fps.
This looks like a pattern emerging, so I tried removing the functions from 3 of the windows, and calling them 10 times from one window. I was expecting the frame rate to be ~6fps, but it remained at 60.
Does anyone know why this is happening? There doesn't seem to be any effect if I remove any other functions from the window drawing methods, for example, gluLookAt() doesn't seem to slow it down.
EDIT: Frame rate limit is set to zero and vsync is false.
This sounds exactly like vertical sync. Each of your windows is waiting for vertical refresh, which is why your rate keeps getting cut in half.
I know you said that vsync is off, but it's possible that your video driver is forcing it. Check your driver settings.
I've written an OpenGL application in Linux through GLX. It uses double buffering with glXSwapBuffers and Sync to VBlank set via NVIDIA X Server Settings. I'm using Compiz and have smooth moving of windows and no tearing (Sync to VBlank enabled in Compiz settings).
But when I
Try to move or resize the OpenGL window or
Move other windows through the area occupied by the OpenGL window
the system stutters and freezes for 3-4 seconds. Moving other
windows outside the area occupied by the OpenGL window is smooth as always.
Moreover the problem only arises if the OpenGL application is in the
loop of producing frames of animation therefore swapping the buffers.
If the content is static and the application is not swapping the buffers there are no problems,moving the various windows is smooth.
Could be a synchronization issue between my application and Compiz?
I don't know if it's still in the same shape as a few years ago, but…
Your description matches very well a Compiz SNAFU. Every window resize triggers the recreation of a texture that will receive the window contents. Texture creation is a costly operation and hence should be avoided. Unfortunately the Compiz developers don't seems the brightest ones, because they did not realize there's an obvious solution to this problem: Windows in X11 can be reparented without much cost (every Window manager does this several times), it's called stacking. Compiz is a window manager.
So why doesn't Compiz keep a desktop sized window around into which it reparents those windows that are about to be resized, gets its constant sized window texture from there and after finishing the resize operation reparents the window into its decoration frame?
I don't know why this is the case. Anyway, some things Compiz does are not very smart.
If you want to fix this, well: Compiz is open source and I just described what to do.