I'm working on a project that requires me to switch between two windows, one using OpenCV and one using OpenGL, both fullscreen.
A GLFW key event opens the OpenCV window fine, but closing the OpenCV window, and attempting to return focus to the OpenGL window results in the window flickering and repeatedly attempting to give focus. This is my code to return focus to the OpenGL window, inside a while loop.
Edit: Ive found out that it only happens when the OpenGL window is fullscreen, which is a requirement of this program. Writing to console shows that the code is being called multiple times
if(!glfwGetWindowAttrib(window, GLFW_FOCUSED))
{
glfwFocusWindow(window);
while(!glfwGetWindowAttrib(window, GLFW_FOCUSED))
{
}
}
I managed to fix my problem by setting the GLFW flag GLFW_AUTO_ICONIFY to false on my openGL window.
The way you posted is not the proper way to set focus.
Use glfwSetWindowCloseCallback to set a close callback.
In that callback is where you set focus to another window.
Related
I have an app that shows (processed) webcam output in an OpenCV window (using imshow) and also, in a different thread, has an OSG window showing some geometry. The problem is that as long as the OSG window is refreshing, the OpenCV window does not update (all the processing in the thread happens, just the call to imshow does nothing). If I drag the OSG window, disabling refreshes, the OpenCV window starts updating normally.
Any ideas why this could happen?
(Windows 8, NVIDIA Quattro K2100, VC++)
You need to call the cv::waitKey() function inside the OpenSceneGraph viewer loop to have your OpenCV windows update. This means that you cannot simply use the OpenSceneGraph function viewer.run(). Instead you have to use the following viewer loop:
while (!viewer.done())
{
cv::waitKey(1);
viewer.frame();
}
The SDL2 window must constantly be ontop of the directX window regardless if the user is clicking away at the directX or SDL2 window.
Why?
I will use this SDL window to toggle music that I want to listen to while still being able to enjoy my video game.
Thanks!
Not sure if it's possible without doing some WinAPI calls, but try messing around with SDL_RaiseWindow().
https://wiki.libsdl.org/SDL_RaiseWindow
Currently developing an APP using C++.
I am displaying multiple sub-windows in a single main window.
When one of the subwindows is put in Full Screen Mode , does the rendering of the other windows stop?
does the rendering of the other windows stop?
That depends on the implementation. If the program is implemented correctly, then the rendering should stop only if the window is fully covered.
Some people like to update the window in a timer callback (which is a bad practice), and then it would continue to render even when covered.
glutDisplayFunc is called only when there is a need to refresh the window.
I'm trying to create a fullscreen application using Win32 and OpenGL. I change the resolution using EnumDisplaySettings and ChangeDisplaySettings and the OpenGL functions work fine. On its WndProc I handle WM_ACTIVATEAPP and detect when the user switched focus to another window, then I minimize the application's window. When the window is maximized again, the window doesn't display properly at all. What could I include to make the application work even after minimizing?
From the question I cannot still say what you are missing and what you already have. Refer to the http://nehe.gamedev.net/. There is a section Opengl base code to setup a window in full screen and switch back to window mode. See if you can get something from there.
I have an application with an OpenGL window as a child window of the main window.
When I display a dialog box above the OpenGL window, it doesn't get drawn. It's like it's not getting WM_PAINT messages. If I can guess the title bar position of the dialog box, I can drag it and it's still responsive.
I realise this might be a vague question, but I was wondering if anyone else has seen this sort of behaviour before and knew of a solution?
I wondered if the Pixel Format Descriptor would make a difference - I had PFD_DRAW_TO_WINDOW, but changing to PDF_DRAW_TO_BITMAP didn't make any difference. I'm not sure what else I should be looking at?
Bugger. Should have given all the details. I was running Windows in a virtual machine on Mac OS X using Parallels. I upgrade from Parallels 3 to 4 and now everything is working fine. I suspect a Parallels video driver issue.
Thanks to all those who answered with suggestions.
Is your opengl window constantly rendering. It is possible that the 3D hardware is simply rendering into an overlay that is overdrawing your dialog box. If you position the dialog box so it overlaps your main window, can you see some of it?
Try to pause rendering into the main display to see if it effects the results.
You will also need to make sure that your window style ensures the results are clipped...
cs.style |= WS_CLIPSIBLINGS | WS_CLIPCHILDREN ;
You should check though all the items mentioned in this MSDN article, as it covers a lot of the basics for getting opengl rendering in a window correctly.
http://msdn.microsoft.com/en-us/library/ms970745.aspx
You may need to switch overlay off. It can be done via forcing back buffer presenting method to copy instead of swap.
Use wglChoosePixelFormatARB and one of parameters should be
WGL_SWAP_METHOD_ARB with value WGL_SWAP_COPY_ARB
This may seems stupid but are you sure your OpenGL window is not flagged "topmost" ?
Does the dialog box disappear also behind borders of your window or just behind the OpenGL rendering rectangle ?