A user could not request to deactivate ARB_compatibility it was forced on them. However, the ARB_compatibility extension posed a problem: the implementation decided whether to define it or not.
#Opengl 2.0 not supported code
Since later versions could remove functionality, it was important that the user be able to ask for a specific version of OpenGL, one that they had written their code against. When OpenGL 3.0 was introduced, a new context creation mechanism was introduced as well. Thus, there was a backwards-compatible specification and a non-backwards compatible specification. The behavior of such implementations is defined with a separate, much larger, OpenGL Specification. The presence of this extension is a signal to the user that deprecated or removed features are still available through the original entrypoints and enumerations. There are other context variations as well.Ī new extension, ARB_compatibility, was introduced when OpenGL 3.1 was revealed. Several techniques were tried, and it has settled down into a division between Core and Compatibility contexts. However, since many implementations support the deprecated and removed features anyway, some implementations want to be able to provide a way for users of higher GL versions to gain access to the old APIs. This includes the Fixed Function Pipeline. OpenGL 3.1 removed almost all of the functionality deprecated in OpenGL 3.0. Many OpenGL functions were declared deprecated, which means that users should avoid using them because they may be removed from later API versions. OpenGL version 3.0 introduced the idea of deprecating functionality. Code written against OpenGL 1.1 could execute just fine on OpenGL 2.1 implementations. Until version 3.0, all versions of OpenGL were fully backwards compatible with earlier ones. However, a single context cannot be current in multiple threads at the same time. The current context is a thread-local variable, so a single process can have several threads, each of which has its own current context. In order for any OpenGL commands to work, a context must be current all OpenGL commands affect the state of whichever context is current. However, contexts do not have to share objects they can remain completely separate from one another. Container Objects are not sharable, nor are Query Objects.Īny object sharing must be made explicitly, either as the context is created or before a newly created context creates any objects. Most OpenGL objects are sharable, including Sync Objects and GLSL Objects. A context's objects can be shared with other contexts. Each context can represent a separate viewable surface, like a window in an application.Įach context has its own set of OpenGL Objects, which are independent of those from other contexts. A process can create multiple OpenGL contexts. Think of a context as an object that holds all of OpenGL when a context is destroyed, OpenGL is destroyed.Ĭontexts are localized within a particular process of execution (an application, more or less) on an operating system. It represents the (potentially visible) default framebuffer that rendering commands will draw to when not drawing to a framebuffer object.
A context stores all of the state associated with this instance of OpenGL. An OpenGL context represents many things.