| | '''OpenGL extension EXT.framebuffer_multisample |
| | |
| | This module customises the behaviour of the |
| | OpenGL.raw.GL.EXT.framebuffer_multisample to provide a more |
| | Python-friendly API |
| | |
| | Overview (from the spec) |
| | |
| | This extension extends the EXT_framebuffer_object framework to |
| | enable multisample rendering. |
| | |
| | The new operation RenderbufferStorageMultisampleEXT() allocates |
| | storage for a renderbuffer object that can be used as a multisample |
| | buffer. A multisample render buffer image differs from a |
| | single-sample render buffer image in that a multisample image has a |
| | number of SAMPLES that is greater than zero. No method is provided |
| | for creating multisample texture images. |
| | |
| | All of the framebuffer-attachable images attached to a framebuffer |
| | object must have the same number of SAMPLES or else the framebuffer |
| | object is not "framebuffer complete". If a framebuffer object with |
| | multisample attachments is "framebuffer complete", then the |
| | framebuffer object behaves as if SAMPLE_BUFFERS is one. |
| | |
| | In traditional multisample rendering, where |
| | DRAW_FRAMEBUFFER_BINDING_EXT is zero and SAMPLE_BUFFERS is one, the |
| | GL spec states that "the color sample values are resolved to a |
| | single, displayable color each time a pixel is updated." There are, |
| | however, several modern hardware implementations that do not |
| | actually resolve for each sample update, but instead postpones the |
| | resolve operation to a later time and resolve a batch of sample |
| | updates at a time. This is OK as long as the implementation behaves |
| | "as if" it had resolved a sample-at-a-time. Unfortunately, however, |
| | honoring the "as if" rule can sometimes degrade performance. |
| | |
| | In contrast, when DRAW_FRAMEBUFFER_BINDING_EXT is an |
| | application-created framebuffer object, MULTISAMPLE is enabled, and |
| | SAMPLE_BUFFERS is one, there is no implicit per-sample-update |
| | resolve. Instead, the application explicitly controls when the |
| | resolve operation is performed. The resolve operation is affected |
| | by calling BlitFramebufferEXT (provided by the EXT_framebuffer_blit |
| | extension) where the source is a multisample application-created |
| | framebuffer object and the destination is a single-sample |
| | framebuffer object (either application-created or window-system |
| | provided). |
| | |
| | This design for multisample resolve more closely matches current |
| | hardware, but still permits implementations which choose to resolve |
| | a single sample at a time. If hardware that implementes the |
| | multisample resolution "one sample at a time" exposes |
| | EXT_framebuffer_multisample, it could perform the implicit resolve |
| | to a driver-managed hidden surface, then read from that surface when |
| | the application calls BlitFramebufferEXT. |
| | |
| | Another motivation for granting the application explicit control |
| | over the multisample resolve operation has to do with the |
| | flexibility afforded by EXT_framebuffer_object. Previously, a |
| | drawable (window or pbuffer) had exclusive access to all of its |
| | buffers. There was no mechanism for sharing a buffer across |
| | multiple drawables. Under EXT_framebuffer_object, however, a |
| | mechanism exists for sharing a framebuffer-attachable image across |
| | several framebuffer objects, as well as sharing an image between a |
| | framebuffer object and a texture. If we had retained the "implicit" |
| | resolve from traditional multisampled rendering, and allowed the |
| | creation of "multisample" format renderbuffers, then this type of |
| | sharing would have lead to two problematic situations: |
| | |
| | * Two contexts, which shared renderbuffers, might perform |
| | competing resolve operations into the same single-sample buffer |
| | with ambiguous results. |
| | |
| | * It would have introduced the unfortunate ability to use the |
| | single-sample buffer as a texture while MULTISAMPLE is ENABLED. |
| | |
| | By using the BlitFramebufferEXT from EXT_framebuffer_blit as an |
| | explicit resolve to serialize access to the multisampled contents |
| | and eliminate the implicit per-sample resolve operation, we avoid |
| | both of these problems. |
| | |
| | The official definition of this extension is available here: |
| | http://www.opengl.org/registry/specs/EXT/framebuffer_multisample.txt |
| | ''' |
| | from OpenGL import platform, constant, arrays |
| | from OpenGL import extensions, wrapper |
| | import ctypes |
| | from OpenGL.raw.GL import _types, _glgets |
| | from OpenGL.raw.GL.EXT.framebuffer_multisample import * |
| | from OpenGL.raw.GL.EXT.framebuffer_multisample import _EXTENSION_NAME |
| |
|
| | def glInitFramebufferMultisampleEXT(): |
| | '''Return boolean indicating whether this extension is available''' |
| | from OpenGL import extensions |
| | return extensions.hasGLExtension( _EXTENSION_NAME ) |
| |
|
| |
|
| | |
