Separated EXT_framebuffer_object, EXT_framebuffer_blit,
EXT_framebuffer_multisample and EXT_packed_depth_stencil don't have the
same functionality as ARB_framebuffer_object (e.g. missing
GL_FRAMEBUFFER_UNDEFINED in glCheckFramebufferStatus()) and separated
read/draw binding is only in EXT_framebuffer_blit, which complicates the
internals.
Checked with Mesa 8/9 and OpenGL 2.1, current one has
ARB_framebuffer_object and also all these four, Mesa 7.7 didn't have
EXT_framebuffer_multisample, but that's a long time ago, so not
supporting these separate extensions shouldn't be an issue.
The problem with unavailable separate binding points remains on OpenGL
ES 2.0, there are three different extensions bringing that
functionality, thus the code managing the available binding points
remains there.
Special RGB values together, RGBA values together, Depth values
together, DepthStencil values together. Left sized internal formats in
the same order, though.
It is deprecated, but many ES2 implementations don't support
EXT_texture_rg, thus this is the only way to have single- and
two-component textures without wasting precious memory. The enum value
isn't exposed on desktop OpenGL and ES3. GL_ALPHA is not supported, as
it doesn't bring any new functionality (it is also single-component
and thus can be interchanged with GL_LUMINANCE).
Advantages:
* The enums were large (600-800 lines) and they polluted the header,
now they are in separate files (except for BufferTexture, which has
the enum small enough to be left in the same file).
* Image classes now don't need to include OpenGL headers, as they were
needed only for the enum values. With advantage of C++11's forward
enum declarations there is no need to include the enum headers
anywhere in implementation, only when particular values are needed.
* The values are now less verbose:
AbstractTexture::InternalFormat::RGB8 // before
TextureFormat::RGB8 // now
* Resolved another "trivial choice" problem (thanks @JanDupal for
introducing this term to me): how to specify the format if there are
ten ways to do it (some being massively confusing):
Image2D::Format f = AbstractImage::Format::RGB; // too long...
Image2D::Format f = Image3D::Format::RGBA; // why 3D? this works?
Image2D::Format f = BufferImage1D::Format::RGBA; // wat?
It is even worse (and more verbose) with textures:
Texture2D::InternalFormat f =
CubeMapTextureArray::InternalFormat::RGB8; // this is allowed?
To have consistent naming this change was done also with
BufferTexture::InternalFormat (now BufferTextureFormat), although there
were no trivial choice issues and the enum isn't too large. But at least
it is now less typing.
Vladimír Vondruš