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.
Related
I'm working on an OpenGL project where there are many scenes. I have successfully implemented the functionality of switching scenes at runtime, so the user can change to another scene by choosing a scene name through the ImGui menu. When that happens, the current scene is deleted to clean up dirty OpenGL internal states, then the new scene will be loaded from a factory pattern. Everything works fine, except that the window will freeze for a few seconds during the transition because unloading/loading scenes takes quite a while to finish.
What I want to do now is to create a loading screen, which will be displayed in between. The task of unloading/loading scenes is scheduled asynchronously using std::async and std::future, so that the caller is non-blocking and my loading screen can show up. However, since I'm creating the new scene in background in another thread, that thread cannot see the OpenGL context in the main thread, as a result, any glxxxx() calls would cause access violation so the new scene cannot be created.
I know that OpenGL is a global state machine which does not support multithreading quite well. I've also read somewhere that it is driver-dependent. Most threads on this topic is old, I wonder if it is still difficult to use multithreading in OpenGL as of 2021. From what I see, loading screen and switching scenes are just very basic functionalities, many applications are able to do so, and I believe there're a bunch of them using OpenGL, why is this problem still not commonly addressed today?
Does anyone know of any external libraries in this regard? Or is there another workaround without using multiple threads?
I would like to have directcomposition render to a texture. Is this possible?
The reason for this is that I would like to be able to render a gpu accelerated windowless transparent flash player activex control to a texture. Something that is usually not possible, but which I hope to achieve with DirectComposition.
It's unlikely that this is possible, to quote MSDN (emphasis mine)
DirectComposition does not offer any rasterization services. An application must use some other software-based or hardware-accelerated rasterization library such as Direct2D or Direct3D to populate the bitmaps that are to be composed. After composing, DirectComposition passes composed bitmap content to Desktop Window Manager (DWM) for rendering to the screen.
As far as I know there are only official APIs to share your offscreen surfaces with DWM, but no API allowing you to get read-access to a DWM surface.
What DWM does allow you is redirecting HWND surfaces, so you can display the surfaces of other HWNDs on your window. This can be done either through DirectComposition (via CreateSurfaceFromHwnd) or the DWM API (via DwmRegisterThumbnail). For an example of the latter look here.
If you want to go the "hacking route" as indicated in your comment, there are undocumented APIs which look like they can give you access to the DWM surfaces, in particular DwmpDxGetWindowSharedSurface sounds promising. Someone else already did some reverse engineering and figured out the signature, but couldn't get it to work (texture works but renders black). This guy seems to have had more luck and was able to render window textures in 3d. I don't understand his language but you seem to have to use DwmpDxUpdateWindowSharedSurface (also undocumented).
You should be aware however that using undocumented functions is not a good idea, Microsoft can change them anytime (even in service pack releases) or remove them completely, since they are only used by Microsoft themselves they have no reason to maintain compatibility. Also there is a good chance that you are going to use them wrong (e.g. you might be missing necessary synchronization and cause random crashes, or worse).
However since the functionality is actually available there is hope that Microsoft may actually open it for puplic use in some future version of Windows.
I have an app that mixes OpenGL with Motif. The big main window that has OpenGL in it redraws fine. But, the sub windows sitting on top of it all go black. Specifically, just the parts of those subwindows that are right on top of the main window. Those subwindows all have just Motif code in them (except for one).
The app doesn't freeze up or dump core. Data is still flowing, and as text fields, etcetera of various subwindows get updated, those parts redraw. Dragging windows across each other or minimizing/unminimizing also trigger redraws. The timing of the "blackout" is random. I run the same 1-hour dataset every time and sometimes the blackout happens 5 minutes into the run and sometimes 30 minutes in, etc.
I went through the process of turning off sections of code until the problem stopped. Narrowed it down more and more and found it had to do with the use of the depth buffer. In other words, when I comment out the glEnable(GL_ENABLE_DEPTH_TEST), the problem goes away. So the problem seems to have something do with the use of the depth buffer.
As far as I can tell, the depth buffer is being cleared before redrawing is done, as it should. There's if-statements wrapped around the glClear calls, so I put messages in there and confirmed that the glClear of the depth buffer is indeed happening even when the blackout happens. Also, glGetError didn't return anything.
UPDATE 6/30/2014
Looks like there's still at least one person looking at this (thanks, UltraJoe). If I remember correctly, it turned out that it was sometimes swapping buffers without first defining the back buffer and drawing anything to it. It wasn't obvious to me before because it's such a long routine. There were some other minor things I had to clean-up, but I think that was the main cause.
How did you create the OpenGL window/context. Did you just get the X11 Window handle of your Motif main window and created the OpenGL context on that one? Or did you create a own subwindow within that Motif window for OpenGL?
You should not use any window managed by a toolkit directly, unless this was some widget for exclusive OpenGL use. The reason is, that most toolkits don't create a own sub-window for each an every element and also reuse parts of their graphics resources.
Thus you should create a own sub-window for OpenGL, and maybe a further subwindow using glXCreateWindow as well.
This is an old question, I know, but the answer may help someone else.
This sounds like you're selecting a bad visual for your OpenGL window, or you're creating a new colormap that's overriding the default. If at all possible, choose a DirectColor 24-plane visual for everything in your application. DirectColor visuals use read-only color cells, but 24 planes will allow every supported color to be available to every window without having to overwrite color cells.
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
I've seen things like this and I was wondering if this was possible, say I run my application
and it will show the render on whatever is below it.
So basically, rendering on the screen without a window.
Possible or a lie?
Note: Want to do this on windows and in c++.
It is possible to use your application to draw on other application's windows. Once you have found the window you want, you have it's HWND, you can then use it just like it was your own window for the purposes of drawing. But since that window doesn't know you have done this, it will probably mess up whatever you have drawn on it when it tries to redraw itself.
There are some very complicated ways of getting around this, some of them involve using windows "hooks" to intercept drawing messages to that window so you know when it has redrawn so that you can do your redrawing as well.
Another option is to use clipping regions on a window. This can allow you to give your window an unusual shape, and have everything behind it still look correct.
There are also ways to take over drawing of the desktop background window, and you can actually run an application that draws animations and stuff on the desktop background (while the desktop is still usable). At least, this was possible up through XP, not sure if it has changed in Vista/Win7.
Unfortunately, all of these options are too very complex to go in depth without more information on what you are trying to do.
You can use GetDesktopWindow(), to get the HWND of the desktop. But as a previous answer says (SoapBox), be careful, you may mess up the desktop because the OS expects that it owns it.
I wrote an open source project a few years ago to achieve this on the desktop background. It's called Uberdash. If you follow the window hierarchy, the desktop is just a window in a sort of "background" container. Then there is a main container and a front container. The front container is how windows become full screen or "always on top." You may be able to use Aero composition to render a window with alpha in the front container, but you will need to pass events on to the lower windows. It won't be pretty.
Also, there's a technology in some video cards called overlays/underlays. You used to be able to render directly to an overlay. Your GPU would apply it directly, with no interference to main memory. So even if you took a screen capture, your overlay/underlay would not show up in the screen cap. Unfortunately MS banned that technology in Vista...