From bfb10d309d97c19a33f9b6758f647186f8e0ddd6 Mon Sep 17 00:00:00 2001
From: Sven Gothel
- A sample implementation is available as
+ An implementation is available as
JOGL, a JogAmp module. The NativeWindow Protocol is included in JogAmp's implementation 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: 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 This interface contains all core OpenGL [ 3.1 .. 3.3 ] 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 This interface contains the OpenGL [ 3.1 .. 3.3 ] compatibility profile,
+ 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 This interface contains all core OpenGL [ 4.0 .. 4.3 ] methods,
+ as well as most of it's extensions defined at the time of this specification. Note: OpenGL [ 4.0 .. 4.3 ] core profile does not includes fixed point functionality. Future extensions will be added with a maintenance update This interface contains the OpenGL [ 4.0 .. 4.3 ] compatibility profile,
+ as well as most of it's extensions defined at the time of this specification. Note: OpenGL [ 4.0 .. 4.3 ] compatibility profile does includes fixed point functionality. Future extensions will be added with a maintenance update This interface contains all core embedded OpenGL methods of ES [ 1.0 .. 1.1 ],
+ as well as most of it's extensions defined at the time of this specification. Future extensions will be added with a maintenance update This interface contains all core embedded OpenGL methods of ES 2.0,
+ as well as most of it's extensions defined at the time of this specification. Future extensions will be added with a maintenance update This interface contains all core embedded OpenGL methods of ES 3.0,
+ 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: 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. 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. Interface containing the common subset of GL2 and GLES1. This interface reflects the fixed functionality of OpenGL, without the immediate mode API. Interface containing the common subset of GL2 and GLES2. This interface reflects the programmable shader functionality of desktop and embedded OpenGL up until GLES2. Interface containing the common subset of core GL4, core GL3, and GLES3. This interface reflects the programmable shader functionality of desktop and embedded OpenGL up until GLES3. 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.JSR 231 Specification Overview
+JOGL Specification Overview
Preface
This specification, an optional set of packages, describes the Java(TM)
bindings to the native OpenGL(R) 3D graphics library profiles:
-
- See Inclusion Criteria explaining the OpenGL profile seperation.
+ See Inclusion Criteria explaining the OpenGL profile separation.
See OpenGL Runtime Requirements.
Dependencies
This binding has dependencies to the following:
-
+
-
-
- The NativeWindow Protocol is included in JogAmp's sample implementation
OpenGL Profile Model
- OpenGL today is not just a single set of functionality, it offers many profiles for different
- purposes, e.g. ES1 and ES2 for mobile, etc.
- JOGL reflects these profiles with an OO abstraction model,
+ OpenGL today is not just a single set of functions, it offers many profiles for different
+ purposes, e.g. ES1, ES2 and ES3 for mobile, GL [ 3.1 .. 4.3 ] core for a programmable shader application, etc.
+ JOGL reflects these profiles with an OO abstraction model,
specifying interfaces encapsulating common subsets.
Package Structure
The packages defined by this specification include:
-
-
- 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:
+
+
-
- Additionally the packages contains interfaces where the main profiles intersect each other.
- These interfaces purposes is to provide common subsets of profiles to be used
- on both, the desktop and the embedded device. These are:
-
- This interface contains all core desktop OpenGL methods through
-version 3.0, inclusive, as well as most of it's extensions defined at the
-time of this specification. OpenGL extensions whose functionality
-was incorporated into core OpenGL until version 3.1, inclusive, are subsumed into the core namespace.
- Note: OpenGL 3.0 is the last completly subsumed version in the specification.
- You need to use a {@link javax.media.opengl.GL3} OpenGL 3.1+ context to benefit
- from new functionality and versions.
- Note: Intersecting OpenGL 3.1 subsumed extensions are subsumed in GL2 as well, to offer the best common GL2GL3 intersection.
- See GL2 Inclusion Criteria.
- See GL2 Runtime Requirements.
- Future extensions will be added with a maintenance update
-
- This interface contains all core, forward compatible, OpenGL methods starting from 3.1,
-inclusive, as well as most of it's extensions defined at the time of this specification.
- Note: OpenGL 3.0 forward compatible, non deprecated functionality is included in the
- 3.1 specification, hence the {@link javax.media.opengl.GL2GL3} implemented interface.
- Note: OpenGL 3.1 forward compatible no more includes fixed point functionality.
- See GL3 Inclusion Criteria.
- See GL3 Runtime Requirements.
- Future extensions will be added with a maintenance update
-
- This interface contains the OpenGL 3.x compatibility profile,
- ie includes all methods as defined in {@link javax.media.opengl.GL2} and {@link javax.media.opengl.GL3}.
- Future extensions will be added with a maintenance update
-
- This interface contains all core embedded OpenGL methods of ES 1.x, with x >= 0,
-inclusive, as well as most of it's extensions defined at the
-time of this specification.
- Future extensions will be added with a maintenance update
-
- This interface contains all core embedded OpenGL methods of ES 2.x, with x >= 0,
-inclusive, as well as most of it's extensions defined at the
-time of this specification.
- Future extensions will be added with a maintenance update
+
-
-
- 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.
-
- Common interface containing the subset of all profiles, GL3bc, GL3, GL2, GLES1 and GLES2.
- This interface reflects common data types, texture and framebuffer functionality.
-
- Interface containing the common subset of GL2 and GLES1.
- This interface reflects only the fixed functionality of OpenGL
-
- Interface containing the common subset of GL3, GL2 and GLES2.
- This interface reflects only the programmable shader functionality of desktop and embedded OpenGL
-
- 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
-
+
+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 javax.media.opengl namespace.
+APIs that share the javax.media.opengl namespace.
Extension suffixes, such as EXT, ARB, and vendor-specific suffixes, are
-retained so as to match C conventions.
+retained so as to match C conventions.
Integer return values that can only be GL_TRUE or GL_FALSE are mapped to
-boolean.
+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.
-
+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
@@ -216,24 +223,24 @@ 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.
-
+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.
-
+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.
-
+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.
+mixed within an API call by an application.
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.
+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.
-
+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.
+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.
+to the underlying native engine.
OpenGL functions and OpenGL extensions have been included in the Java bindings +according the following rules:
GL3/gl3.h
.GL/glcorearb.h
.GL_ARB_compatibility
, is chosen because:
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 the JSR. In order to avoid fragmentation,
+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.
-
+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 specfication.
+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.
- -The 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.
+ ++JOGL provides {@link com.jogamp.opengl.JoglVersion} implementing {@link com.jogamp.common.util.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. +
+ +http://www.jcp.org/en/jsr/detail?id=231-
-http://www.opengl.org/registry/doc/glspec41.core.20100725.withchanges.pdf-
-http://www.opengl.org/registry/doc/glspec41.compatibility.20100725.withchanges.pdf- -
-http://www.opengl.org/registry/doc/glspec30.20080923.pdf- -
-http://www.opengl.org/registry/doc/glspec21.20061201.pdf- -
http://www.opengl.org/registry/- - - -
-http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.24.pdf- -
-http://www.khronos.org/registry/gles/specs/1.1/es_full_spec_1.1.12.pdf- -
-http://www.khronos.org/registry/gles/- -
http://www.opengl.org/documentation/specs/glu/glu1_3.pdf- -
http://www.opengl.org/about/arb/index.html- -