2005 Sams Publishing glBindFramebuffer 3G glBindFramebuffer bind a named framebuffer object void glBindFramebuffer GLenum target GLuint framebuffer target Specifies the target to which the framebuffer object is bound. The symbolic constant must be GL_FRAMEBUFFER. framebuffer Specifies the name of a framebuffer object. glBindFramebuffer lets you create or use a named framebuffer object. Calling glBindFramebuffer with target set to GL_FRAMEBUFFER and framebuffer set to the name of the new framebuffer object binds the framebuffer object name. When a framebuffer object is bound, the previous binding is automatically broken. Framebuffer object names are unsigned integers. The value zero is reserved to represent the default framebuffer provided by the windowing system. Framebuffer object names and the corresponding framebuffer object contents are local to the shared object space of the current GL rendering context. You may use glGenFramebuffers to generate a set of new framebuffer object names. The state of a framebuffer object immediately after it is first bound is three attachment points (GL_COLOR_ATTACHMENT0, GL_DEPTH_ATTACHMENT, and GL_STENCIL_ATTACHMENT) each with GL_NONE as the object type. While a non-zero framebuffer object name is bound, GL operations on target GL_FRAMEBUFFER affect the bound framebuffer object, and queries of target GL_FRAMEBUFFER or of framebuffer details such as GL_DEPTH_BITS return state from the bound framebuffer object. While framebuffer object name zero is bound, as in the initial state, attempts to modify or query state on target GL_FRAMEBUFFER generates an GL_INVALID_OPERATION error. While a non-zero framebuffer object name is bound, all rendering to the framebuffer (with glDrawArrays and glDrawElements) and reading from the framebuffer (with glReadPixels, glCopyTexImage2D, or glCopyTexSubImage2D) use the images attached to the application-created framebuffer object rather than the default window-system-provided framebuffer. Application created framebuffer objects (i.e. those with a non-zero name) differ from the default window-system-provided framebuffer in a few important ways. First, they have modifiable attachment points for a color buffer, a depth buffer, and a stencil buffer to which framebuffer attachable images may be attached and detached. Second, the size and format of the attached images are controlled entirely within the GL and are not affected by window-system events, such as pixel format selection, window resizes, and display mode changes. Third, when rendering to or reading from an application created framebuffer object, the pixel ownership test always succeeds (i.e. they own all their pixels). Fourth, there are no visible color buffer bitplanes, only a single "off-screen" color image attachment, so there is no sense of front and back buffers or swapping. Finally, there is no multisample buffer, so the value of the implementation-dependent state variables GL_SAMPLES and GL_SAMPLE_BUFFERS are both zero for application created framebuffer objects. A framebuffer object binding created with glBindFramebuffer remains active until a different framebuffer object name is bound, or until the bound framebuffer object is deleted with glDeleteFramebuffers. Queries of implementation-dependent pixel depths and related state are derived from the currently bound framebuffer object. These include GL_RED_BITS, GL_GREEN_BITS, GL_BLUE_BITS, GL_ALPHA_BITS, GL_DEPTH_BITS, GL_STENCIL_BITS, GL_IMPLEMENTATION_COLOR_READ_TYPE, GL_IMPLEMENTATION_COLOR_READ_FORMAT, GL_SAMPLES, and GL_SAMPLE_BUFFERS. GL_INVALID_ENUM is generated if target is not GL_FRAMEBUFFER. glGet with argument GL_FRAMEBUFFER_BINDING glDeleteFramebuffers, glFramebufferRenderbuffer, glFramebufferTexture2D, glGenFramebuffers, glGet, glGetFramebufferAttachmentParameteriv, glIsFramebuffer Copyright 2008 Khronos Group. This material may be distributed subject to the terms and conditions set forth in the Open Publication License, v 1.0, 8 June 1999. http://opencontent.org/openpub/.