2005
Sams Publishing
glBindFramebuffer
3G

# glBindFramebuffer

bind a named framebuffer object

## C Specification

                    void glBindFramebuffer
                    GLenum target
                    GLuint framebuffer

## Parameters

`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.

## Description

`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.

## Notes

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`.

## Errors

`GL_INVALID_ENUM` is generated if `target` is not `GL_FRAMEBUFFER`.

## Associated Gets

glGet with argument `GL_FRAMEBUFFER_BINDING`

## See Also

glDeleteFramebuffers, glFramebufferRenderbuffer, glFramebufferTexture2D, glGenFramebuffers, glGet, glGetFramebufferAttachmentParameteriv, glIsFramebuffer

## Copyright

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/.