framebuffer_multisample.py :  » Game-2D-3D » PyOpenGL » PyOpenGL-3.0.1 » OpenGL » GL » EXT » Python Open Source

Home
Python Open Source
1.3.1.2 Python
2.Ajax
3.Aspect Oriented
4.Blog
5.Build
6.Business Application
7.Chart Report
8.Content Management Systems
9.Cryptographic
10.Database
11.Development
12.Editor
13.Email
14.ERP
15.Game 2D 3D
16.GIS
17.GUI
18.IDE
19.Installer
20.IRC
21.Issue Tracker
22.Language Interface
23.Log
24.Math
25.Media Sound Audio
26.Mobile
27.Network
28.Parser
29.PDF
30.Project Management
31.RSS
32.Search
33.Security
34.Template Engines
35.Test
36.UML
37.USB Serial
38.Web Frameworks
39.Web Server
40.Web Services
41.Web Unit
42.Wiki
43.Windows
44.XML
Python Open Source » Game 2D 3D » PyOpenGL 
PyOpenGL » PyOpenGL 3.0.1 » OpenGL » GL » EXT » framebuffer_multisample.py
'''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 thespec import 
  
  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 import 
  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 thatsurfacewhen import 
  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 traditionalmultisampledrenderingallowedthe import 
  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_blitasan import 
  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,constants,constant,arrays
from OpenGL import extensions,wrapper
from OpenGL.GL import glget
import ctypes
from OpenGL.raw.GL.EXT.framebuffer_multisample import *
### END AUTOGENERATED SECTION
www.java2java.com | Contact Us
Copyright 2009 - 12 Demo Source and Support. All rights reserved.
All other trademarks are property of their respective owners.