Occassionally I hit places where I'd want to get an OpenGL framebuffer object, but where I'm not interested about opening a window of any kind.
Is it possible to create an opengl context without attaching it to a window of any kind?
Yes! you can use the desktop window as the window passed to OpenGL- as long as you don't try to display anything on it ;)
Just Call GetDesktopWindow and pass the result as an argument when creating new OpenGL window.
http://www.opengl.org/wiki/Creating_an_OpenGL_Context
According to this Web page, WGL_ARB_create_context can be used to create a context without a window. I have not actually tried it myself. I used freeGLUT to create the context and then rendered off-screen to a framebuffer+renderbuffer. I exit the program without ever calling glutMainLoop. It is klugy, but it works for my purposes.
Yes, you can perform off-screen rendering with OpenGL, but the exact way to set it up is dependent on the operating system.
The closest you get to an OS independent way would be to use Mesa 3D, but then your off-screen rendering would not be hw accelerated.
Related
How do I set the number of samples in the default framebuffer, given by Windows?
I found this page, but although I use glew, there is no available wglChoosePixelFormatARB function in my context. What could be the cause of this?
With WGL, you can only set the pixel format for a window once when you create the context, and you can only call the wglChoosePixelFormatARB() function once the client driver is loaded, and the client driver is only loaded once you have an OpenGL context. Yes, that's circular. So, this means you have to do the following:
Create a window with an OpenGL context.
Get the function pointer for wglChoosePixelFormatARB().
Destroy the window, and create a new window with the desired pixel format.
If you've got any sense in you, you'll use SDL or GLFW to do this for you, because it's just a bunch of plumbing you have to write, there's no value in learning how to do it, and you probably want to get some real work done. SDL/GLFW/etc. is how 99% of the OpenGL game devs out there do it.
If you really want to do this yourself and get stuck, look at the SDL or GLFW source code to see how they do it.
In SDL, the src/video/windows/SDL_windowsopengl.c file has a function WIN_GL_ChoosePixelFormatARB() which does what you want. Also note the function WIN_GL_LoadLibrary().
In GLFW, the src/win32_window.c file has a function _glfwPlatformCreateWindow() which does what you want.
P.S. GLEW is a bit broken with core contexts and modern cards, so watch out. There are other GL loaders out there.
Is it possible to hide OpenGL window and the rendering are still running? I use glutHideWindow which will never trigger display function.
If that is not possible, is it possible in the program to change the focus of the current window? I want to run opengl program but I don't need that window. In fact, I want to use the framebuffer that opengl updates at each frame in another program. But it's always annoying to toggle between the two programs. (They both have window)
Is it possible to hide OpenGL window and the rendering are still running?
Yes and No to both parts of the question.
If you hide a window, all the pixels of the window's viewport will fail the pixel ownership test when rendering. So you can't use a hidden window as a drawable for OpenGL to operate on.
What you need is an off-screen drawable to draw to.
The modern variant are Framebuffer Objects (FBOs), which you can create on a regular OpenGL context, that might even work on a hidden window. FBOs take some drawable attachments (render buffers, textures) and allow OpenGL to draw to these instead to the window.
An older method are PBuffers, also widely supported, but not as easy to use as FBOs.
Note that if you want to perform off-screen rendering on Linux/X11 the X server must be active, i.e. owning the VT so that the GPU actually processes the commands. So you can't just start an X server "in the background" but have another X server use the display device.
After creating the window, you can use glutHideWindow() to go offscreen. Then you still render as nomal and use glReadPixels to read back and get buffer to use it later.
There is an interesting browser framework called Awesomium, which is basically a wrapper around the Chromium browser engine.
I'm interested in using it to redistribute WebGL-based games for the desktop. However Awesomium only supports rendering using a pixel buffer sent to the CPU, even though the WebGL context itself is based on a real hardware-accelerated OpenGL context. This is inefficient for real-time high-performance games and can kill the framerate on low-end machines.
Awesomium may eventually fix this, but it got me thinking: is it possible to search a process for an offscreen OpenGL context and render it directly to a window? This would avoid the inefficient rendering method, keeping rendering entirely on the GPU. I'm using a native C++ app on Windows, so presumably this will involve WGL specifics. Also since Chromium is a multithreaded browser engine it may involve finding an OpenGL context on a different thread or event a different process. Is it possible?
is it possible to search a process for an offscreen OpenGL context and render it directly to a window?
No, it it not possible. If the opengl context is created for the OS buffer, then it is not possible to redirect it to other buffer and other opengl context.
Maybe you can use shared opengl resources (if both opengl contexts are created using such option).
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 OpenGL Application (using Ogre3d and SDL, not directly calling OpenGL) and we are trying to change the Resolution at runtime. It seems that we need to re-initialize our OpenGL context with the new Resolution but a number of items are breaking along the way. On Linux it seems to work for a while, then we get graphical corruption on screen. On Windows it simply crashes the next time we try to render a frame. We have forced the reloading of textures in Ogre, and if we rendering nothing but textures (no 3d models) then this works fine, but any 3d models cause a crash and reloading before rendering them has no effect.
Here is a link to an in depth explanation of Ogre3d calls we are doing: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=62825
All we really need to know is, When re-initializing an Opengl context what resources need to be restored?
Why does adjusting an OpenGL context affect other resources? Is it the way OpenGL works, or did one of the libraries we use introduce this issue? Could we have added this issue without knowing it?
Did you have a look at this forum thread ?
SDL seems to destroy the OpenGL when changing resolution. In this case, all you GL resources are destroyed with the context.
One possible solution would be to create another 'dummy' GL context, sharing resources with you 'real' GL context, and to keep it alive with SDL destroys the 'main' context. This way most of your resources should survive.
Note that some resources can't be shared, textures and VBO are fine, but VAO can't.
OpenGL support was added SDL after its surface code had been established. That's why changing the size of a SDL window is destructive. You were pointed to OpenGL context sharing and its caveats. However I'd avoid the problem alltogether by not using SDL for creating an OpenGL window. You can use all the other facilities SDL provides without a window managed by SDL, so the only thing that would change is input event processing and how the window's created. Instead of SDL I'd use GLFW, which like SDL requires you to implement your own event processing loop, so using GLFW as a drop-in replacement for OpenGL window and context creation is straightforward.