dja-sheffield wrote on Monday, December 07, 2015:
I have an application using 3 full-screen GLFW windows, using POSIX to switch so that one process (not thread) is active and the other 2 processes are waiting. However, the only way I found to switch between the windows is to use glfwIconifyWindow and glfwRestoreWindow but the switching takes half a second and is not very clean. Is there a better way to switch between full-screen windows processes?
This is a little unusual. I don’t think there is a faster way to switch.
Probably the fastest you could get is a maximized non decorated window (see https://github.com/glfw/glfw/issues/266 for progress on maximized) though this still would not be top-most so the OS menu would still be present (i.e. it’s not quite fullscreen).
Is there a reason why you’ve chosen to go for multiple processes rather than use one process switching between the three different functionalities?
dja-sheffield wrote on Monday, December 07, 2015:
I am trying to port software which ran in real-time on three PCs (50 fps) to a single PC. The processes would not be able to run in real-time as a single process but they are mutually independent (only one is active at any one time), so I can have one active process and two waiting processes. They are also three different applications: one OpenGL display, one OpenGL GUI and one OpenScenegraph. My idea was to adapt the existing code with Posix so that the processes started and stopped using semaphores. It works well but the window switching on Windows7 with MinGw is awful (but does work). I am currently seeing if Linux is any better. Rather irriatingly, some GLFW functions don’t apply in full screen modes (which is needed for all three processes). Changing to one process wih three threads would need a major rewrite whereas Posix does enable this to work. So my question is really to ask if the swapping can be made cleaner. (BTW: I have moved from glut to GLFW as this is not possible in glut and GLFW seems to work well with MinGw and Linix).
FYI on my Windows PC switching between two fullscreen desktop resolution GLFW apps is very fast (just using ALT-TAb to test). Your problem may be with the MinGw POSIX layer (prehaps use native windows synchronization), or with the fact your rendering is not at desktop resolution so a resolution switch is required.
Re: “some GLFW functions don’t apply in full screen modes” - which ones are your referring to?
Note that if your applications are not active all at the same time, then you don’t need to run them as three threads if you use one process, as you could instead just switch the active update/render functions used. However this looks non trivial (though do-able) for OSG due to it’s framework style architecture.
dja-sheffield wrote on Monday, December 07, 2015:
My application works correctly in terms of switching processes and inter-process communication, but only if I manually switch Linux (full screen) windows using alt-tab. When I enter a new active process, I call glfwMakeContextCurrentWindow(window) and glfwRestoreWindow(window). When I leave a process that is no longer active, I call glfwIconifyWindow(window) and glfwMakeContextCurrent(NULL), where ‘window’ is a correctly formed GLFWwindow* (the graphics is correct). Is this the correct way to swap between windows. Is there something else I should be doing? I would have assumed that GLFW switches correctly between processes as well as threads - hope I’m not wrong. I have made a small demonstration of the problem with four small C processes. The application is real-time flight simulation. Thanks for your help.
GLFW does not handle inter-process OpenGL & Windowing, as this is done at the OS and driver levels.
So you don’t need to call glfwMakeContextCurrent - indeed I’d recommend not doing so.
If removing the context change doesn’t improve things, and ALT-TAB works well, then your issue is with the fashion in which you handle the inter-process switching using semaphores. It sounds like you might be causing the iconified process to suspend, which could cause problems with window messages.
To ensure your messages keep getting polled, I would recommend trying sem_timedwait with 200ms or so and remaining iconified if this fails with ETIMEDOUT.
dja-sheffield wrote on Wednesday, December 09, 2015:
My software is now working on Ubuntu. I uninstalled GLFW 3.0 (synaptic version) and installed version 3.2 from the GLFW website. That was all I needed to do. I did not need to implement any Xlib window management. I have retained glfwMakeContextCurrent. There is a small ‘glitch’ as the full window changes, presumably when Linux iconifies the current window. I will experiment a bit further, as I was about to implement XRaiseWindow and XLowerWindow every time I changed the full screen window. If anyone would like copies of my test software (4 concurrent processes) let me know.
dja-sheffield wrote on Thursday, December 10, 2015:
Doug. I have two demonstration programs. One runs under Linux with Posix semaphore and uses shm for shared memory. The other runs under Windows7/MinGw and uses Windows semaphores and shared memory. The GLFW code in both versions is identical, except for the specific semaphore and shared meory calls. Both are using GLFW version 3.2. The Windows version runs without error. The Linux version is flaky and hangs after 4 or 5 window swap operations. My best guess is that there is a bug in the Linux library for GLFW (and version 3.0 did not work at all). Is there anyone developing GLFW I could contact to see if the problem is in the GLFW library? They are small test programs constsing of four processes: a master process and three OpenGL process running full screen graphics.
The issue list for GLFW is on it’s Github repo: https://github.com/glfw/glfw/issues
There are a number issues related to fullscreen switching, so your best bet is to first see if any relate to what you’re finding. If they’ve been fixed, trying the latest code from github might help.
Given that you’re doing something unusual, it would help if you can do as much debugging as you can to identify what’s happening (I would also remove the glfwMakeContextCurrent call), so I would download the latest source code version from Github and compile with cmake so you can debug the code and atempt to find out where it hangs.
I’d also recommend trying to window swap by ALT+TAB to see if this also generates the same problem, or if it’s only occuring when using your synchronization code to handle the swapping.
dja-sheffield wrote on Friday, December 11, 2015:
That fixes the problem and the window swapping is much cleaner than windows. GLFW enables me to run my multi-processing application which is just not possible with glut. Many thanks for your help.
Glad you have this working! For future reference for anyone encountering this, when you say ‘that fixes the problem’ what did you mean by ‘that’?
dja-sheffield wrote on Friday, December 11, 2015:
To clarify - it fixes the problem of a window freezing in Linux (unrecoverably) where there are several OpenGL/GLFW processes (not threads) and when the application swaps between processes (and their windows).
I meant what was it you did which fixed the problem :
dja-sheffield wrote on Saturday, December 12, 2015:
I updated from version 3.1.2 on the GLFW download page to the version on the Github (also 3.1.2 but different) - that was all I did. I notice that the MingW version of my software works 100%, but the identical Ubuntu version of my software now fails 1 time in 20, rather than 1 time in 5 with the previous version. I still suspect the GLFW Linux library has a bug with swapping full screen windows whereas the MinGw version does not. My software is only three small test programs to validate multiple OpenGL processes.