Can't test EXT_debug_label, as that is apparently OSX 10.9-only. Added
GL tests for all implemented objects. KHR_debug is selected first, if
that is not available, fall back to EXT_debug_label. If neither is
available, the functions are no-op.
I hope EXT_debug_label gets replaced by KHR_debug later, thus it is now
only "emulated" through KHR_debug enums.
Resolves some linker errors in Windows, removes code bloat from Platform
namespace (previously it was copied in _every_ *Application).
Originally this was in Platform namespace because I thought that it
would be possible to have one version of Magnum library for both desktop
and ES and the actual Application would determine which GL edition will
be used. Fun idea, but it would remove the static checks (e.g.
accidentaly using geometry shaders on ES), which isn't worth it.
It contains a few (un)packing functions present in ARB_gpu_shader5, but
isn't mentioned anywhere except GLSL 4.20 changelog (and there it has
its old name, ARB_shading_language_pack2f). It might be supported on
machines where ARB_gpu_shader5 can't be supported (GL3 HW).
Passing pointer as function parameter will now mean that it is possible
to pass `nullptr`. Some code examples now look like the parameter is
copied instead of referenced, which is misleading. Updated the
documentation to reflect that more clearly.
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.
Not relying on GL version when asking for extensions, i.e. Mesa might
know glGetStringi() even if it reports OpenGL 2.1 only. Similarly in
shadingLanguageVersionStrings(), not all HW is capable of 4.3, but
GL_NUM_SHADING_LANGUAGE_VERSIONS might be supported on GL3 HW too (not
my case, though).
Robust *Framebuffer::read() access, ability to query robust buffer
access behavior in Context::flags(), ability to check graphics reset
status and reset notification policy in Renderer.
OpenGL 3.0 specification is awesomely confused with extensions. The ones
listed in specs don't have the complete functionality and references
to related ARB extensions are nowhere to be found.
Framebuffer::attach*() doesn't need the target at all (meaning the
attachment will be used for both reading and drawing), another
misunderstanding on my side.
Now the extension is used on all places where it can be used (except for
unimplemented features).
Viewport position and size is managed separately for each framebuffer
and glViewport() is called in bind() (and also from setViewport(), if
the framebuffer is currently bound) if the viewport differs from
current state. If used only one framebuffer size through whole
application lifetime, glViewport() doesn't need to be called at all.
Buffered* hinted that it has something to do with caching, streaming or
whatever. "Buffer texture" is now also consistent with naming in
specification.
On OpenGL 3.3 context it was checking for support of all 3.0, 3.1 and
3.2 extensions even if isExtensionSupported() didn't use that
information at all.