Currently, the default framebuffer can’t be used in many of the ways that textures or renderbuffers can be. You can render to them, copy to them with glBlitFramebuffer, but you can’t do things like bind them as images or textures and so forth.
One of the reasons for this is that the default framebuffer can be resized by the windowing system. Images need to have a specific, fixed size, so having them be resized can be an issue.
To deal with this issue, I propose the ability to lock images within the default framebuffer. This will prevent the framebuffer from being resized. If a window is resized, then something implementation-dependent will happen. It may be rescaled, it may fill empty areas with garbage, whatever.
It would be simple:
glLockDefaultFramebuffer();
While the default framebuffer is locked, you can get a texture object for the various images. As such:
glTextureDefaultFramebuffer(GL_BACK);
This will return a texture view of the 2D storage for the back buffer of the default framebuffer. So it’s immutable. Every call to this will return a new texture object (from an unused texture name, as if from glGenTextures
). So repeated calls will create new views to the same storage. Obviously, if the framebuffer is not locked, this will fail with an error.
The sticky point is this:
glUnlockDefaultFramebuffer();
Obviously, we would need that function. But what exactly does it mean? What happens to those texture views that were created? The simplest thing would be for any use of them (besides deletion) after unlocking the default framebuffer to become undefined behavior.
An alternative implementation of this concept that avoids the pesky unlock issue is to add a WGL/GLX_CONTEXT_FIXED_BIT_ARB to the attribute flags. If this flag is set, then the context has a size fixed at the time of its creation. In such a context, glTextureDefaultFramebuffer
will return a valid texture object as defined above; if the context wasn’t created with this flag, it returns 0.