I have written an OpenGL application that is always rendering full-screen. Occasionally I switch displays while the app is running, (physically connect a different monitor or projector) which may also result in a change of resolution. How can I detect when the display has changed resolution so that I can update my OpenGL output window, and adapt the content to the new resolution?
What I'm looking for is an event or signal of some kind that I can observe when the display mode changes due to a different physical display being connected.
I expect there's probably some way of getting notified - maybe it's an xlib thing? Just not sure where the event or signal might come from.
I'm working in OpenGL ES, C++, Linux ARM (aarch64).
Related
I'm writing a C++ application whose main window needs to receive real-time data from a server and draw plots and histograms in realtime based on this data. I'm using GTK3 (actually its C++ binding gtkmm) and Cairo.
In particular, data is received every 1 second from the network, and refresh happens every time the data is received, thus every 1 second. Refresh is done by calling the invalidate_rect() method for the entire drawing area, whose on_draw() even redraws all figures and plots using the newly received data.
Now, the application works but it's extremely unreliable. In particular, it freezes very often, especially when the CPU load increases. The CPU usage of my application, as well as memory, are very low. Suddenly the window becomes grey and unresponsive, and I need to kill it with Ctrl-C, since even pressing the window close icon doesn't work.
I'm wondering: is it the wrong approach to call invalidate_rect() in the scenario above? What is a better way, using GTKMM/Cairo, to obtain smooth graphics in a reliable way?
When I switch one of my monitor to fullscreen mode, sometimes the other monitors just become black and won't show anything. Did I do something wrong or it is just some bug?
I created a window, and then created a swapchain binded to that window. And I called the swapchain's SetFullScreenState with first parameter true, and second parameter the IDXGIOutput object of the monitor I wanted to switch fullscreen. Sometimes it works fine, but sometimes all the other monitors are lost (with only the fullscreened one showing things).
My graphics card is Radeon HD6750, and driver version is 12.3.
I found the MulitMon10 sample has the same problem, while some games don't. Or do Skyrim and The Tales of Monkey Island use D3D or OpenGL...?
This question is two years old. I just came across it.
I had a similar issue with DX11, sometimes happening in debug version, systematicaly in release version.
In my paradigm, the primary monitor hosts a console and an optional 'press buttons' GUI. The secondary monitor (one among available ones) is the fullscreen application window where 2D professional images are displayed and GPU transformed using 1D and 3D lookup tables.
Having the primary monitor going blank was a show stopper. All needed dialogs are childs of the console window (thus, opening on the primary monitor). The secondary monitor is a motion picture digital projector .... enough 'blabla'.
So, my solution was to create the swapchain in windowed mode while the targeted window was already in fullscreen mode.
Do not ask me why. It works for me. Here is a bit more:
First, my display window is set to fill the entire monitor surface ( no border, no everything).
Second, I create the swapchain for this window with “windowed = true”.
In facts, even if it looks fullscreen, it is windowed. With no border, it works the same as far as displaying/rendering 2D images is concerned. Feeding directly the backbuffer works too.
Then, and only then, you can switch the backbuffer to real administrative fullscreen. Since this operation is extremely brutal for the eyes, I tend to only do it when absolutely necessary. In effects, Win7 will reset the entire desktop (thus, all monitors, all windows) and create multiple light flashes.
When going real fullscreen after the backbuffer is created, I never experienced the desagrement of being stuck in the midle of a desktop reset (back to the original question).
To be complete, there is a difference between ‘Windowed fullscreen’ and ‘Real fullscreen’. Something you may use.
Windowed fullscreen: other windows/dialogs will overlap your 2D creation.
Real fullscreen: other windows/dialog should stay underneath (not visible, but there).
Toggling between the two modes upon need would be nice, except the desktop reset stress is an heavy penalty to live with.
I am writing a game in C++ using SDL 1.2.14 and the OpenGL bindings included with it.
However, if the game is in fullscreen and I Alt - Tab out then back into the game, the results are unpredictable. The game logic still runs. However, rendering stops. I only see the last frame of the game that was drawn before the Alt-tab
I've made sure to re-initialize the OpenGL context and reload all textures when I get an SDL_APPACTIVE = 1 event and that seems to work for only one Alt - Tab, then all subsequent Alt - Tabs will stop rendering (I've made sure SDL_APPACTIVE is properly being handled each time and setting the context accordingly.)
I'd hazard a guess that SDL does something under the hood when minimizing the application that I'm not aware of.
Any ideas?
It's a good pratice to "slow down" your fullscreen application when it looses the focus. Two reasons:
User may need to Alt-Tab and do something important (like closing a heavy application that's hogging the resources). When he switches, the new application takes control, and the OS must release resources from your app as needed
Modern OS uses a lot of GPU - this means it needs to release some graphics memory to work.
Try shutting down every GL resource you use when APPACTIVE=0 and alloc them again on APPACTIVE=1. If this solves, it was "your fault". If it does not solves, it's SDL (or GL or OS) bug.
EDIT: s/SO/OS/g
When trying to implement a simple OpenGL application, I was surprised that while it is easy to find plenty of examples and documentation on advanced rendering stuff, the Win32 framework is poorly documented and even most samples and tutorials do not implement this properly even for basic cases, not mentioning advanced stuff like multiple monitors. Despite of several hours of searching I was unable to find a way which would handle Alt-Tab reliably.
How should OpenGL fullscreen application respond to Alt-Tab? Which messages should the app react to (WM_ACTIVATE, WM_ACTIVATEAPP)? What should the reaction be? (Change the display resolution, destroy / create the rendering context, or destroy / create some OpenGL resources?)
If the application uses some animation loop, suspend the loop, then just minimize the window. If it changed display resolution and gamma revert to the settings before changing them.
There's no need to destroy OpenGL context or resources; OpenGL uses an abstract resource model: If another program requires RAM of the GPU or other resources, your programs resources will be swapped out transparently.
EDIT:
Changing the window visibility status may require to reset the OpenGL viewport, so it's a good idea to either call glViewport apropriately in the display/rendering function, or at least set it in the resize handler, followed by a complete redraw.
We have an application which uses an OpenGL render context in a subwindow to display a large bitmap. However, when a user remotely connects to a box running this app, the openGL display stops working, most likely due to the reduced texture resolution.
While we can detect the remote desktop connection starting/ending using WTS_REMOTE_CONNECT, the openGL context does not switch to the virtual driver when trying to determine the new max texture resolution.
Completely restarting the openGL subthread hangs on ChoosePixelFormat, this wont return until I am logged in locally again, otherwise this would be the "bad" solution.
It seam that application is badly written.
Code that is responsible for detecting context changes and reacting to them accordingly, do not exist or is buggy. Any way, you can not do much, unless you have access to source code. Also you can report is as a bug to vendor or provider from whom you bought it.