framebuffer_object.specs

Cited Official
https://www.opengl.org/registry/specs/EXT/framebuffer_object.txt

Following are source contents

Overview

    This extension defines a simple interface for drawing to rendering
    destinations other than the buffers provided to the GL by the
    window-system.

    In this extension, these newly defined rendering destinations are
    known collectively as "framebuffer-attachable images".  This
    extension provides a mechanism for attaching framebuffer-attachable
    images to the GL framebuffer as one of the standard GL logical
    buffers: color, depth, and stencil.  (Attaching a
    framebuffer-attachable image to the accum logical buffer is left for
    a future extension to define).  When a framebuffer-attachable image
    is attached to the framebuffer, it is used as the source and
    destination of fragment operations as described in Chapter 4.

    By allowing the use of a framebuffer-attachable image as a rendering
    destination, this extension enables a form of "offscreen" rendering.
    Furthermore, "render to texture" is supported by allowing the images
    of a texture to be used as framebuffer-attachable images.  A
    particular image of a texture object is selected for use as a
    framebuffer-attachable image by specifying the mipmap level, cube
    map face (for a cube map texture), and z-offset (for a 3D texture)
    that identifies the image.  The "render to texture" semantics of
    this extension are similar to performing traditional rendering to
    the framebuffer, followed immediately by a call to CopyTexSubImage.
    However, by using this extension instead, an application can achieve
    the same effect, but with the advantage that the GL can usually
    eliminate the data copy that would have been incurred by calling
    CopyTexSubImage.

    This extension also defines a new GL object type, called a
    "renderbuffer", which encapsulates a single 2D pixel image.  The
    image of renderbuffer can be used as a framebuffer-attachable image
    for generalized offscreen rendering and it also provides a means to
    support rendering to GL logical buffer types which have no
    corresponding texture format (stencil, accum, etc).  A renderbuffer
    is similar to a texture in that both renderbuffers and textures can
    be independently allocated and shared among multiple contexts.  The
    framework defined by this extension is general enough that support
    for attaching images from GL objects other than textures and
    renderbuffers could be added by layered extensions.

    To facilitate efficient switching between collections of
    framebuffer-attachable images, this extension introduces another new
    GL object, called a framebuffer object.  A framebuffer object
    contains the state that defines the traditional GL framebuffer,
    including its set of images.  Prior to this extension, it was the
    window-system which defined and managed this collection of images,
    traditionally by grouping them into a "drawable".  The window-system
    API's would also provide a function (i.e., wglMakeCurrent,
    glXMakeCurrent, aglSetDrawable, etc.) to bind a drawable with a GL
    context (as is done in the WGL_ARB_pbuffer extension).  In this
    extension however, this functionality is subsumed by the GL and the
    GL provides the function BindFramebufferEXT to bind a framebuffer
    object to the current context.  Later, the context can bind back to
    the window-system-provided framebuffer in order to display rendered
    content.

    Previous extensions that enabled rendering to a texture have been
    much more complicated.  One example is the combination of
    ARB_pbuffer and ARB_render_texture, both of which are window-system
    extensions.  This combination requires calling MakeCurrent, an
    operation that may be expensive, to switch between the window and
    the pbuffer drawables.  An application must create one pbuffer per
    renderable texture in order to portably use ARB_render_texture.  An
    application must maintain at least one GL context per texture
    format, because each context can only operate on a single
    pixelformat or FBConfig.  All of these characteristics make
    ARB_render_texture both inefficient and cumbersome to use.

    EXT_framebuffer_object, on the other hand, is both simpler to use
    and more efficient than ARB_render_texture.  The
    EXT_framebuffer_object API is contained wholly within the GL API and
    has no (non-portable) window-system components.  Under
    EXT_framebuffer_object, it is not necessary to create a second GL
    context when rendering to a texture image whose format differs from
    that of the window.  Finally, unlike the pbuffers of
    ARB_render_texture, a single framebuffer object can facilitate
    rendering to an unlimited number of texture objects.


Glossary of Helpful Terms

        logical buffer:

One of 



the color, 
the depth, or 
the stencil buffers 


of the framebuffer.

        framebuffer:


The collection of logical buffers and 
associated state
defining where the output of GL rendering is directed.

        texture:


an object which consists of one or more 2D arrays of pixel images
associated states
can be used as a source of data during the texture-mapping process described in section 3.8.

        texture image:


one of the 2D arrays of pixels that 
are part of a texture object as defined in section 3.8.  
Texture images contain and define the texels of the texture object.

        renderbuffer:


A new type of storage object which contains a single 2D array of pixels
associated state that 
can be used as a destination for pixel data written during the rendering process described in Chapter 4.

        renderbuffer image:


The 2D array of pixels that 
is part of a renderbuffer object.  
A renderbuffer image contains and defines the pixels of the renderbuffer object.

        framebuffer-attachable image:


A 2D pixel image that 
can be attached to one of the logical buffer attachment points of a framebuffer object.  
Texture images and renderbuffer images are two examples of framebuffer-attachable images.

        attachment point:


The set of state which 
references a specific framebuffer-attachable image, and 
allows that framebuffer-attachable image to be used to store the contents of a logical buffer of a framebuffer object.  
There is an attachment point state vector for each color, depth, and stencil buffer of a framebuffer.

        attach:
            The act of connecting one object to another object.
            An "attach" operation is similar to a "bind" operation
            in that 

            both represent a reference to the attached or bound
            object for the purpose of managing object lifetimes and 

            both enable manipulation of the state of the attached or bound
            object.

            However, an "attach" is also different from a "bind" in that
            "binding" an unused object creates a new object, while
            "attaching" does not.  Additionally, "bind" establishes a
            connection between a context and an object, while "attach"
            establishes a connection between two objects.

            Finally, if object "A" is attached to object "B" and object
            "B" is bound to context "C", then in most respects, we treat
            "A" as if it is <implicitly> bound to "C".

        framebuffer attachment completeness:
            Similar to texture "mipmap" or "cube" completeness from
            section 3.8.10, defines a minimum set of criteria for
            framebuffer attachment points.  (for complete definition,
            see section 4.4.4.1)

        framebuffer completeness:
            Similar to texture "mipmap cube completeness", defines a
            composite set of "completeness" requirements and
            relationships among the attached framebuffer-attachable
            images.  (for complete definition, see section 4.4.4.2)

________________________________________________________________