See: Description
Inclusion Criteria explains the OpenGL profile separation.
See OpenGL Runtime Requirements.
An implementation is available as JOGL, a JogAmp module.
Other API bindings are available as JogAmp modules:The NativeWindow Protocol is included in JogAmp's implementation
JOGL reflects these profiles with an OO abstraction model, specifying interfaces encapsulating common subsets.
This package contains all Java bindings for all OpenGL profiles.
See Inclusion Criteria explaining the OpenGL profile seperation.
See OpenGL Runtime Requirements.
The main OpenGL profile interfaces are:
com.jogamp.opengl.GL2 interface
This interface contains all OpenGL [ 1.0 .. 3.0 ] methods, as well as most of it's extensions defined at the time of this specification.
OpenGL extensions whose functionality was incorporated into core OpenGL ≤ 3.0, are subsumed into the core namespace.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GL3 interface
This interface contains all OpenGL [ 3.1 .. 3.3 ] core methods, as well as most of it's extensions defined at the time of this specification.
Note: OpenGL [ 3.1 .. 3.3 ] core profile does not includes fixed point functionality.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GL3bc interface
This interface contains all OpenGL [ 3.1 .. 3.3 ] compatibility methods, as well as most of it's extensions defined at the time of this specification.
Note: OpenGL [ 3.1 .. 3.3 ] compatibility profile does includes fixed point functionality.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GL4 interface
This interface contains all OpenGL [ 4.0 .. 4.5 ] core methods, as well as most of it's extensions defined at the time of this specification.
Note: OpenGL [ 4.0 .. 4.5 ] core profile does not includes fixed point functionality.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GL4bc interface
This interface contains all OpenGL [ 4.0 .. 4.5 ] compatibility profile, as well as most of it's extensions defined at the time of this specification.
Note: OpenGL [ 4.0 .. 4.5 ] compatibility profile does includes fixed point functionality.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GLES1 interface
This interface contains all OpenGL ES [ 1.0 .. 1.1 ] methods, as well as most of it's extensions defined at the time of this specification.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GLES2 interface
This interface contains all OpenGL ES 2.0 methods, as well as most of it's extensions defined at the time of this specification.
Future extensions will be added with a maintenance update
com.jogamp.opengl.GLES3 interface
This interface contains all OpenGL ES [ 3.0 .. 3.1 ] methods, as well as most of it's extensions defined at the time of this specification.
Future extensions will be added with a maintenance update
Additionally the packages contains interfaces resembling intersecting common profiles. These common profiles may be utilize for cross profile code supposed to either run on desktop and mobile devices, or across GL profiles themselves:
com.jogamp.opengl.GLBase interface
Common interface containing the profile type identification and conversion methods.
Used to query which specialized profile class an instance of this object actually is and offering a protocol to convert it to these types.
com.jogamp.opengl.GL interface
Common interface containing the subset of all profiles, GL4bc, GL4, GL3bc, GL3, GL2, GLES1, GLES2 and GLES3.
This interface reflects common data types, texture and framebuffer functionality.
com.jogamp.opengl.GL2ES1 interface
Interface containing the common subset of GL2 and GLES1.
This interface reflects the fixed functionality of OpenGL, without the immediate mode API.
com.jogamp.opengl.GL2ES2 interface
Interface containing the common subset of GL2 and GLES2. Interface is almost GLES2 complete.
This interface reflects the programmable shader functionality of desktop and embedded OpenGL up until GLES2.
com.jogamp.opengl.GL3ES3 interface
Interface containing the common subset of core GL3 and GLES3. Interface is almost GLES3 complete, lacking GL_ARB_ES3_compatibility extension.
This interface reflects the programmable shader functionality of desktop and embedded OpenGL up until GLES3.
com.jogamp.opengl.GL4ES3 interface
Interface containing the common subset of core GL4 and GLES3. Interface is GLES3 complete w/o vendor extensions.
This interface reflects the programmable shader functionality of desktop and embedded OpenGL up until GLES3.
com.jogamp.opengl.GL2GL3 interface
Interface containing the common subset of core GL3 (OpenGL 3.1+) and GL2 (OpenGL 3.0), also known as the OpenGL 3.0 forward compatible, non deprecated subset.
This interface reflects only the programmable shader functionality of desktop OpenGL
This package contains bindings for the OpenGL Graphics System Utility (GLU) Library version 1.3, inclusive, with the exception of the GLU NURBS routines which are not exposed.
The rules for creating the Java language binding are described in the following sections. These rules should be followed as closely as possible for all future APIs that share the com.jogamp.opengl namespace.
Extension suffixes, such as EXT, ARB, and vendor-specific suffixes, are retained so as to match C conventions.
Integer return values that can only be GL_TRUE or GL_FALSE are mapped to boolean.
OpenGL functions that take pointer arguments fall into several categories:
Functions that take a typed pointer (e.g., GLfloat *) argument for immediate use are given two bindings. The first takes a Java primitive array with a type that matches the C pointer type (i.e., GLfloat* maps to float[]). The second takes a typed Buffer object (i.e., GLfloat* maps to FloatBuffer). An example of an OpenGL API in this category is glColor3fv.
Functions that take an untyped (void*) pointer argument for deferred use are given a single binding that takes a Buffer object. The Buffer may be of any type allowable by the function (and compatible with the other arguments to the function), but must be direct. That is, it may not have been created from a Java primitive array using the wrap method. The functions that fall into this category generally have names ending with the suffix "pointer." An example of an OpenGL API in this category is glVertexPointer. Because these functions do not consume the data located at the given pointer immediately, but only at some unspecified later time, it is not possible to use a Java primitive array whose memory location may change.
Functions that take a typed (e.g., GLfloat*) pointer argument for deferred use are given a single binding that takes a typed Buffer object (i.e., GLfloat* maps to FloatBuffer). The Buffer must be direct. That is, it may not have been created from a Java primitive array using the wrap method. An example of an OpenGL API in this category is glFeedbackBuffer.
Methods that read or write a specific number of values from an array or Buffer argument do not read or write any subsequent elements of the array or Buffer.
An outgoing C char* pointer, if representing a null-terminated, read-only C string, maps to a Java String. An outgoing C char** pointer, if similarly representing an array of read-only C strings, maps to a Java String[] (array of String objects). All other char* pointers, including those representing mutable C strings as used in some Get methods, are mapped to byte[] and ByteBuffer.
Also, methods that accept multiple Buffer arguments require all direct or all non-direct Buffers. Direct and non-direct buffers should never be mixed within an API call by an application.
ByteBuffer.allocateDirect(...).order(ByteOrder.nativeOrder());.
The byte order of the ByteBuffer indicates how multi-byte values such as
int and float are stored in the Buffer either using methods like putInt and
putFloat or views such as IntBuffer or FloatBuffer. The Java bindings perform
no conversion or byte swapping on the outgoing data to OpenGL, and the native
OpenGL implementation expects data in the host CPU's byte order, so it is
essential to always match the byte order of the underlying platform when
filling Buffers with data.
This feature is known as "auto-slicing," as it mimics the effect of calling slice() on the Buffer object without the overhead of explicit object creation.
In the interest of efficiency, the Java API does not generally throw exceptions. However, running an application with the DebugGL composable pipeline, which is part of the API, will force an exception to be thrown at the point of failure.
Many errors are defined by OpenGL merely to set the error code, rather than throwing an exception. For example, passing a bad enumerated parameter value may result in the error flag being set to GL.GL_INVALID_VALUE. Attempting to check for such errors in the binding layer would require either replicating the error-checking logic of the underlying engine, or querying the error state after every function. This would greatly impact performance by inhibiting the ability of the hardware to pipeline work.
An implementation should take care to validate arguments correctly before invoking native methods that could potentially access memory illegally. In particular, methods that validate the contents of an array (such as a list of GL attributes) or a Buffer should take precautions against exploits in which a separate thread attempts to alter the contents of the argument during the time interval following validation but preceding passage of the argument to the underlying native engine.
See GLSharedContextSetter interface
for details.
OpenGL functions and OpenGL extensions have been included in the Java bindings according the following rules:
com.jogamp.opengl.GL3 interface
GL/glcorearb.h.GL_ARB_compatibility, is chosen because:
com.jogamp.opengl.GL2 interface
Bindings for OpenGL extensions not covered in this specification may be supplied by individual vendors or groups. Such bindings may be considered for inclusion in a future version of this specification. In order to avoid fragmentation, vendors creating extension bindings should expose new extensions using the method GL.getExtension. This method is intended to provide a mechanism for vendors who wish to provide access to new OpenGL extensions without changing the public API of the core package.
Names for added extension methods and extension-defined constants and Java bindings for C parameters should follow the guidelines set forth in this specification.
Therefore, any usage of these APIs is both platform and implementation specific.
GL4 Desktop RequirementsGL3 Desktop RequirementsGL2 Desktop RequirementsThe JOGL reference implementation require at least OpenGL version 1.1, due to it's dynamical function binding starting with OpenGL 1.2.
In future revisions of the API, this minimum standard may be raised.
GLES3 RequirementsGLES2 RequirementsGLES1 Requirements
JOGL provides JoglVersion implementing JogampVersion,
which provides users access to the specification and implementation version,
the build date and source code repository branch name and it's latest commit identifier.
Copyright 2010 JogAmp Community.